When you’ve done as much ConfigMgr 2007 Operating System Deployment as I have (and even if you haven’t!) it becomes rapidly obvious that things don’t always go to plan on the first go. Generally, when creating new OSD Task Sequences, I’m plagued by one or two minor errors that need a little investigation.
Thankfully (or not, depending on how you like looking at log files) ConfigMgr 2007 logs everything. Unfortunately, when in WinPE mode for OSD, reading those log files can be a real pain in the behind. Trace32 (and the relatively recent Trace64 for our 64 bit counterparts) were never included in WinPE boot media, which is a tad odd considering the requirement for it.
Fear not, as it is totally possible to integrate Trace into your own boot image. I tend to do this whenever I’m working on a customer OSD engagement as it makes my life, and more importantly, the customers life much easier. No more trawling through Notepad .log files people – upgrade your boot images now! Read the rest of this entry »
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.
Over the last couple of weeks, I have pushed out numerous Windows Updates to bring a collection of computers into compliance. One thing I’ve noticed on a good percentage of machines (15% ish) is that a couple of updates in particular fail to install.
This has been puzzling me for some time, and during my research, I noticed that despite the ConfigMgr Software Update app indicating these updates are required, they are actually already installed on the machines.
The software updates causing this headache are:
It seems that despite actually being already installed, Windows Update still tries to install the update, thus causing a failure as shown in the screenshot above. It’s also worth noting that other updates I approved after these two, successully install, so this isn’t an issue with the Windows Update agent. The SCCM log files also indicated that the updates install without error.
After much head scratching, I found I could resolve this issue by doing the following.
NET STOP wuauserv
C:\Windows\SoftwareDistribution
Now the next time the Windows Update agent runs, it will see that the updates are already installed and present you with the status of ‘Installed’ instead of failed.
In some environments there is a requirement to ensure the local administrator account is renamed to something other than the default ‘Administrator’. The prime reason for this is security. It makes a hackers life just a touch easier if he knows the default administrators username. For this reason, it’s common practice to rename it to something else.
There are two ways to achieve this in a Windows environment. Firstly, you can configure a Group Policy to do just that. Secondly, you can rename the account as part of your Operating System Deployment. The latter is what I’m interested in.
You can achieve this by adding a new step into your OSD Task Sequence. I place this at the very end of my Task Sequence to ensure it gets applied after any administrator related tasks. The computer is then set to reboot afterewards to ensure it is applied successfully.
Add a Run Command Line step into your Task Sequence and add the following code to the Command Line text box.
wmic UserAccount where Name="Administrator" call Rename Name="NewName"
Change “NewName” to whatever you want the administrator account to be renamed to and save the Task Sequence. Your local administrator account will now be renamed accordingly as part of your Operating System Deployment. I haven’t tried myself, but I’d imagine you could run this step as part of your build and capture Task Sequence. In theory, this should eliminate the need to add the step to each of your OSD Task Sequences.
Now that we have a major new version of Adobe Reader in the form of 9.4.0, it’s time to get busy and deploy the new software to your enterprise. This article is a refresher on how best to deploy the software to your enterprise in the most effective manner.
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.