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! Continue reading.
Whenever I perform a new installation of ConfigMgr for a customer, one post-deployment task at the top of my agenda is the integration of Microsoft Deployment Toolkit (MDT) 2010 Update 1.
The process to integrate MDT is extremely straight forward and takes two minutes – but the advantages it brings to Operating System Deployment are huge! Some of my favourites are:
So what are you waiting for, let’s get to it. Continue reading.
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…
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.