What?
If you are using Workspace ONE and the “Reset This PC” feature of Windows 10, you may already had this problem.
The Workspace ONE Agent doesn’t get installed at the end of “Reset This PC”, instead some other “random” MSI gets installed or the installation of this random MSI fails.
Why?
To fully understand this problem you need to know how the Push-Button Reset works, how to extend it and (at least partly) what VMWare is doing in the Batch-file they used to extend “Reset This PC”. I’m focusing only on the part which causes the problem.
The reason why a wrong MSI gets installed at the end of the Push-Button Reset is pretty trivial (and I’m wondering why, after 1.5y, it’s still not fixed by VMWare) and located at the beginning.
Take a look at the VMWareRefreshBackup.cmd located at C:\Recovery\OEM, lines 186 to 201:
for /F "tokens=*" %%A in ('reg query %MSIREGKEYNAME%') DO (
SET USERDATA=%%A
echo PROCESSING SID !USERDATA! >>%LOGFILE%
for /F "tokens=*" %%A in ('reg query !USERDATA!\Products' ) DO (
set SUBKEY=%%A
REM Find for Product Code for AirwatchAgent and AWMDMagent
for /F "tokens=1-3 delims={}" %%A in ('reg query "!SUBKEY!\InstallProperties" /v ModifyPath') DO SET MODIFYPATH1=%%B
call :SUB_FIND_AND_COPY "!MODIFYPATH1!" "!SUBKEY!" "%AWAGENT%"
call :SUB_FIND_AND_COPY "!MODIFYPATH1!" "!SUBKEY!" "%AWMDMAGENT%"
REM Find for Provisioning agent by Product name
for /F "tokens=3-4 delims= " %%A in ('reg query "!SUBKEY!\InstallProperties" /v DisplayName') DO SET DISPLAYNAME1=%%A%%B
call :SUB_FIND_AND_COPY "!DISPLAYNAME1!" "!SUBKEY!" "%AWPROVAGENT%"
)
)
I’ll ask you one question and you probably will see the problem here:
What happens if the Registry value “ModifyPath” of the next key isn’t set right after the key which belongs to the AWAgent.msi?
You’re right, the script “thinks” it’s the AWAgent.msi and backs up the (now wrong) MSI, overwritting the already copied (correct) AWAgent.msi.
So what to do?
Pretty easy, just add 2 lines to the code:
for /F "tokens=*" %%A in ('reg query %MSIREGKEYNAME%') DO (
SET USERDATA=%%A
echo PROCESSING SID !USERDATA! >>%LOGFILE%
for /F "tokens=*" %%A in ('reg query !USERDATA!\Products' ) DO (
set SUBKEY=%%A
set MODIFYPATH1=
set DISPLAYNAME1=
REM Find for Product Code for AirwatchAgent and AWMDMagent
for /F "tokens=1-3 delims={}" %%A in ('reg query "!SUBKEY!\InstallProperties" /v ModifyPath') DO SET MODIFYPATH1=%%B
call :SUB_FIND_AND_COPY "!MODIFYPATH1!" "!SUBKEY!" "%AWAGENT%"
call :SUB_FIND_AND_COPY "!MODIFYPATH1!" "!SUBKEY!" "%AWMDMAGENT%"
REM Find for Provisioning agent by Product name
for /F "tokens=3-4 delims= " %%A in ('reg query "!SUBKEY!\InstallProperties" /v DisplayName') DO SET DISPLAYNAME1=%%A%%B
call :SUB_FIND_AND_COPY "!DISPLAYNAME1!" "!SUBKEY!" "%AWPROVAGENT%"
)
)
These 2 lines make sure that both variables aren’t set at the beginning of every run of the for-loop and therefore avoiding this problem.
Be aware, the Batch-file could be replaced during an update of the AirWatch Agent.
Was this helpful?
1 / 0