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 »
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 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.
I’ve been implementing Operating System Deployment with System Center Configuration Manager 2007 R2 SP2 over the last couple of weeks, with the intention of PXE booting Unknown Clients into the Task Sequence Wizard.
After running a few successful deployments, I started to notice PXE boots were failing. The PXE server seemed to be ignoring client boot requests as if they were ‘Known’ to SCCM. This was the case even after deleting the resource from the SCCM database. This behaviour was validated by looking into the SMSPXE.LOG file on the PXE server. I noticed the following lines were present.
No Boot Action for Device (17898) found ProcessDatabaseReply: No Advertisement found in Db for device
I began to investigate the PXE server configuration and noticed that after deleting the resource from the SCCM database and restarting the Windows Deployment Services service, the computer was correctly identified by PXE boot as an Unknown Computer and successfully booted into the Task Sequencer.
It seems to be the PXE server cache is causing the resource ID to remain in memory so it is no longer discovered as an Unknown Computer. Luckily, I discoverd a fix that seems to work for me. The PXE server cache timeout is determined by the following registry key. In my case, it was set to 0, which I assume is infinite. I ammeded this value to 300 (decimal) and restarted the Windows Deployment Services service on the PXE server and all seems to work as expected. I can image a bare metal computer, delete it from the SCCM database and after approximately two minutes, I can PXE boot it as an Unknown Computer again to reimage it.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\PXE\CacheExpire
Be warned though, I believe this is set for a reason. I’d imagine that if you are using a mandatory advertisement to the Unknown Computers collection, the machine will re-PXE boot each time the OS deployment tries to reboot as part of the OSD Task Sequence. Though this hasn’t been tested and isn’t a problem for me as I am using optional advertisements.
The following report will pull back information on all servers in your SCCM environment with disk space and volume information. It can be useful when trying to total up your disk space usage and working out where you can shed a few gigabytes.
SELECT SYS.Name, RSYS.Description0, LDISK.DeviceID0, LDISK.Description0, LDISK.VolumeName0, LDISK.FreeSpace0, LDISK.Size0, LDISK.FreeSpace0*100/LDISK.Size0 as C074 FROM v_FullCollectionMembership SYS join v_GS_LOGICAL_DISK LDISK on SYS.ResourceID = LDISK.ResourceID JOIN v_R_System RSYS ON SYS.ResourceID = RSYS.ResourceID WHERE LDISK.DriveType0 =3 AND LDISK.Size0 > 0 AND SYS.CollectionID = 'SMS000DS' ORDER BY SYS.Name, LDISK.DeviceID0
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.