Interestingly, there are no obvious errors, and because of how the product is installed, the SWD job will show success. However, if you look for the SBS/PXE services, they are missing, along with most of the task handler folders. You might see an error in the system logs about an MSI error if you look hard enough but it's hard to catch and there are two possible errors. However, the Agent logs will simply show the Deployment Site Server Components product started and ran to completion.
There are at least two possible reasons, both resulting in a similar 1720 MSI failure which can be seen if you run the installer manually:
- Task Services have not been installed on the designated Site Server. By default, the filter to which the DS Site Components applies looks for Task and Package, but if you manually add a system or systems to that policy, you might run into this. The MSI, if run manually, will fail with a message that Task Server is not present and exit. If you run the batch file, no message will be seen and it will run to completion.
- WMI may be broken. As with item #1 above, you will not see an error if run via the batch file. However, if you run the MSI manually, you will see a failed call for an object in the VBScript. Normally, this failed call happens if a DLL is swapped with an EXE (Google search), but it can also be caused by WMI damage.
The solutions listed below correspond directly to the options in the Cause:
- First, we don't recommend modifying the filter/target to which the Policy applies. Remember that in DS 7.1, Task and Package are required on a DS site server for the images to be pulled from that location. So, to resolve this issue, please go to Site Servers and add the target system as a Task and Package server first. Once that is done, the installation should continue past this error. The MSI can be called directly by double-clicking on it with no startup switches.
- WMI may have to be repaired. This is not a Symantec issue, but we found the following information from Microsoft and other forums useful in one case:
- "WMI Diagnosis Utility -- Version 2.0" found at www.microsoft.com was able to tell us several issues about what was broken. Google searches for some of these then lead to other fixes as listed below.
- From a command prompt, we ran "rundll32 wbemupgd, RepairWMISetup" which will attempt a repair on WMI. We then ran the diagnostics utility which ran longer, but still had errors.
- Several DLLs were still not registered among other things, so we ran the following 3 in succession from the same command prompt (line 1 swaps to the default WMI directory from wherever you are, line 2 re-registers all DLL's, line 3 re-registers all EXE's):
- cd /d %windir%\system32\wbem
- for %i in (*.dll) do RegSvr32 -s %i
- for %i in (*.exe) do %i /RegServer
- At this point, the customer was able to re-run the DS Task Handler MSI manually and it ran to completion.