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.
Anyone who works with software deployments will know where I’m coming from on this. Adobe Reader has to be the single most time consuming piece of software when it comes to software packaging and distribution. With such a large user base and ever increasing targeted threats, it’s no wonder we find ourselves with critical updates to deploy. Often more than one a month.
The trouble with Adobe Reader updates is that they aren’t particularly easy to distribute. Sure, you can download the MSI installer from Adobe’s website and use the Adobe Customisation Wizard to create a neat little MST file to transform the install with all your company’s standard settings, but have you ever tried installing the new MSI over a previous version? Not so easy now huh.
For some unknown reason, Adobe engineer their Reader installations in such a way that simply deploying the new MSI isn’t enough. For instance, you can’t simply push out Adobe Reader 9.3.3 and hope that it updates all the previous 9.3.2 installations. You first have to uninstall all previous versions.
Adobe updates usually come in the form of MSP files. These files are designed to patch your existing installation points. It’s important to note that this is only the case for quarterly updates. Security updates cannot be used to patch your administrative installation point.
For this example, I’m going to patch my Adobe Reader 9.3.0 administrative installation point with the MSP for 9.3.3.
Oh but wait, another fly in the ointment. You can’t patch a 9.0 administrative point with 9.3.3 directly. You must follow this order of patching:
9.3.0 > 9.3.2 > 9.3.3
Start by downloading all of your files. You’ll need:
Fire up a command line window, and run the following. This command will integrate your MSP with your installation point.
msiexec.exe /a "path to acroread.msi in admin point" /p "path to AdbeRdrUpd932_all_incr.msp" /qb
You’ll notice the installer wizard configuring your computer. Note that this is actually configuring your installation point, not your computer.
Repeat the above with the AdbeRdrUpd933_all_incr.msp file. You will now have an installation point with Adobe Reader 9.3.3 ready to roll.
If like me you have Microsoft System Center Configuration 2007 at your disposal, you can make use of my batch file script that I have created to remove all previous versions of Adobe Reader prior to installing the new 9.3.3 version. Simply set the script to run before the installation for Adobe Reader 9.3.3 and you should find the install takes place with no errors.
For the script to work fully, you’ll need to add the MSIZap executable into the same folder as the script. This can be downloaded for free as part of the Windows Installer Cleanup Utility (found here…). You only need msizap.exe for the script to work, forget about the other files. MsiZap is a very useful tool. Check out the command line syntax I use and experiment to your hearts content.
If you only have Group Policy at your disposal, I’m sure it wouldn’t be too hard to modify the script to call the install after the uninstalls have taken place. Hope this helps!
REM *** MSI Uninstall Adobe Reader 6
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A00000000001} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 7
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A70900000002} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 8.0
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A80000000002} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 8.1
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A81000000002} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 8.1.4
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A81300000003} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 9.0
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A90000000001} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 9.1
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A91000000001} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 9.2
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A92000000001} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 9.3
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A93000000001} REBOOT=Supress /qn
REM *** Zap Uninstall Adobe Reader 6
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A00000000001}
REM *** Zap Uninstall Adobe Reader 7
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A70900000002}
REM *** Zap Uninstall Adobe Reader 8.0
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A80000000002}
REM *** Zap Uninstall Adobe Reader 8.1
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A81000000002}
REM *** Zap Uninstall Adobe Reader 8.1.4
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A81300000003}
REM *** Zap Uninstall Adobe Reader 9.0
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A90000000001}
REM *** Zap Uninstall Adobe Reader 9.1
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A91000000001}
REM *** Zap Uninstall Adobe Reader 9.2
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A92000000001}
REM *** Zap Uninstall Adobe Reader 9.3
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A93000000001}This custom report can be useful for identifying workstations that have not rebooted recently. I use this report to identify users that may not have received the latest Group Policy settings or other items that require a reboot to be enforced. As well a report query, you must also add a prompt (no code necessary) named ‘Days‘. This is the variable that will store the amount of days you wish to search back. Set the default to 7 and do not allow nulls.
SELECT CS.Name0 AS [Hostname], CS.UserName0 AS [Last User], DateDiff(Day, OS.LastBootUpTime0, GetDate()) AS [Uptime (in Days)], OS.LastBootUpTime0 AS [Last Reboot Date], WS.LastHWScan AS [Last Hardware Inventory] FROM DBO.v_GS_WORKSTATION_STATUS WS LEFT OUTER JOIN DBO.v_GS_Operating_System OS ON WS.ResourceID = OS.ResourceID LEFT OUTER JOIN DBO.v_GS_COMPUTER_SYSTEM CS ON CS.ResourceID = OS.ResourceID LEFT OUTER JOIN DBO.v_GS_SYSTEM SYS ON SYS.ResourceID = OS.ResourceID LEFT OUTER JOIN DBO.v_R_SYSTEM RSYS ON RSYS.ResourceID = CS.ResourceID WHERE SYS.SystemRole0 = 'Workstation' AND DateDiff(Day, OS.LastBootUpTime0, GetDate()) > @Days ORDER BY CS.Name0
This custom report for SCCM 2007 allows an administrator to determine which servers have been rebooted in the last 7 days. If you wish to change the 7 day interval, all you need to do is change the number 168 to the number of days, specified in hours.
SELECT CS.Name0 AS [Hostname], RSYS.Description0 AS [Directory Description], DateDiff(Hour, OS.LastBootUpTime0, WS.LastHWScan) AS [Uptime (in Hours)], OS.LastBootUpTime0 AS [Last Reboot Date], WS.LastHWScan AS [Last Hardware Inventory] FROM DBO.v_GS_WORKSTATION_STATUS WS LEFT OUTER JOIN DBO.v_GS_Operating_System OS ON WS.ResourceID = OS.ResourceID LEFT OUTER JOIN DBO.v_GS_COMPUTER_SYSTEM CS ON CS.ResourceID = OS.ResourceID LEFT OUTER JOIN DBO.v_GS_SYSTEM SYS ON SYS.ResourceID = OS.ResourceID LEFT OUTER JOIN DBO.v_R_SYSTEM RSYS ON RSYS.ResourceID = CS.ResourceID WHERE SYS.SystemRole0 = 'Server' AND DateDiff(Hour, OS.LastBootUpTime0, GetDate()) < 168 ORDER BY CS.Name0