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 »
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. 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.
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…
When working in environments where you have multiple storage locations for your files, there are often times where you wish there were a way to centralise your data so it is always readily available. In my case, I work from a laptop computer with secondary disk with all my essential data. I also have a network attached storage (NAS) device which hosts a copy of my data. Out of the box, Microsoft Windows doesn’t offer any synchronisation tools. Enter SyncToy.
During an SP2 upgrade of a System Center Configuration Manager 2007 R2, I noticed that the installation was taking a lot longer than I thought it should. The installation screen was still active (the progress bar was scrolling along as normal) but the task had not moved on from Initialize Configuration Manager site in some time. Over two hours in fact.
Reviewing the C:\ConfigMgrSetup.log file revealed that the install had indeed stalled and the last couple of entries in my logfile looked like this.
08-04-2010 12:55:21 Enabling monitoring for inbox def Status Manager. 08-04-2010 12:55:21 Enabling monitoring for inbox def Scheduler (LAN Outbox). 08-04-2010 12:55:21 Enabling monitoring for inbox def Scheduler (Requests). 08-04-2010 12:55:21 Enabling monitoring for inbox def Data Loader. 08-04-2010 12:55:21 Enabling monitoring for inbox def Software Inventory Processor (Site). 08-04-2010 12:55:21 Enabling monitoring for inbox def Despooler. 08-04-2010 12:55:21 Enabling monitoring for inbox def Replication Manager (Incoming). 08-04-2010 12:55:21 Enabling monitoring for inbox def Discovery Data Manager. 08-04-2010 12:55:21: Status Modules\Status Modules 08-04-2010 12:55:21: Components Status Module: SMS Server\Components 08-04-2010 12:55:21: Components Status Module: SMS Client\Components 08-04-2010 12:55:21: Components Status Module: SMS Provider\Components
After some research, I discovered that the reason this was occurring was I had a huge collection of .CCR files within the ccr.box folder on my site server. When I say huge collection, I mean over a million files. After deleting them all, which took around 30 minutes, the installation jumped right to the next stage.
It’s worth noting, the .CCR files were actually in a sub-folder of ccr.box, so I’m assuming that SCCM SP2 update searches for all .CCR files in the complete ccr.box folder hierarchy.