I recently spotted this issue while trying to install a software package to a Distribution Point. Other packages seemed to be installing without a problem. The package in question was the Microsoft Deployment Toolkit package, which I was intending to use with Operating System Deployment.
Delving into the distmgr.log file didn’t shed too much light on the issue, but there was an interesting error code in there which you should look out for.
Win32 Error = 5
After a little poking around in some event logs on the Distribution Point server (running Win2008 R2 SP1) I noticed the McAfee Antivirus Engine reporting some strange errors. Funnily enough, it was blocking access to one of the files included in the package, Autorun.INF.
Once I disabled the AV protection and removed and re-added the package to the DP, it installed as expected.
This issue had me running in circles for an hour or two. Initially, I had thought it must be WebDAV extension filtering blocking access to the .VBS files within the package, but after tweaking the settings, I ended up looking elsewhere. That is when I spotted the AV event log errors!
Lesson learned: Always disable AV on a DP. Alternatively, try and exclude the DP folder from protection if AV is a must have.
It’s been a while since I last posted, but I couldn’t quite resist this little nugget. It’s been bothering me for a few days now and I’ve finally found the fix.
I’m in the process of creating a demo environment for SCCM 2007 R3 in a local VMware Workstation environment. Everything was working fine and dandy until I came to deploy a Windows 7 x86 image to a bare metal VM.
The Task Sequence would initialise and the Partition and Format step would work, but as soon as it went to move on to the next step, I’d receive the error 0×80004005 with a 15 minute countdown to restart.
Eventually, I narrowed down the issue. I basically discovered that the VM was originally a Windows XP VM, therefore no x64 extensions were installed. Seeing as I was booting to a x64 boto image, I figured this could be the cause. Low and behold, changing the properties of the Task Sequence to use the x86 boot image solved the issue! The machine now builds.
So all those hours of throwing in different versions of drivers were wasted, It really was that easy…
Now that Adobe have released version 9.4.0 of their popular (and flawed) PDF viewer, it had become time for me to package the software for enterprise deployment. I stumbled across an issue with the Adobe Customisation Tool and web browser integration.
It seems there is a bug when creating a transform when setting the Allow PDF files to open in Browser option. If you set this option to enabled, once the software is deployed and you try to open a PDF within a web browser window, the following error is displayed:
The Adobe Acrobat/Reader that is running can not be used to view PDF files in a web browser. Adobe Acrobat/Reader version 8 or 9 is required."
I’m still unsure as to the exact cause of this issue, but trawling the web seems to indicate that this is indeed a result of a bug within the Customisation Tool. My workaround was to set the option to Disable and regenerate the transform. This allows you to open a PDF from a web browser but forces the PDF to open within an Adobe Reader window, as opposed to inline within your web browser.
Thanks Adobe.
Whilst recently configuring Windows Deployment Services on a Windows Server 2003 R2 Enterprise SP2 system, I noticed the error code 0xE0000102 appear while running through the server configuration. The configuration bombs out and you are left with an unconfigured WDS server.
I think I have this one nailed. It seems that if your system had Windows Server 2003 Service Pack 2 installed before you joined a domain, you will hit this error.
I noticed this in my lab environment, where I commonly build a virtual server template with 2003 R2 SP2. All new servers are cloned from there. Once the clone is created, I join them to a domain if required, so SP2 exists prior to domain joining.
The answer? Remove SP2, reboot, reinstall.