Archive for January, 2012
Came across this very useful article and FAQs about SCCM in a multi-domain or multi-forest scenario.
A challenge with installing software updates during a task sequence is that it may occur where not all updates are applied on the first pass. The workaround is run software updates, run a VB Script or PowerShell script to force another scan, then run a software updates task again. Others have posted their scripts on this before, so it’s nothing new. However, I failed trying to quickly locate those scripts. So I’m just posting my own of what I use….
'========================================================================== ' AUTHOR: Nick Moseley , http://t3chn1ck.wordpress.com ' DATE : 7/30/2010 ' COMMENT: Initiates an SCCM client scan ' Script from http://msdn.microsoft.com/en-us/library/cc144313.aspx ' Updated 7/15/11 to include a sleep before exiting script '========================================================================== ' Set the required variables. actionNameToRun = "Updates Source Scan Cycle" ' Create a CPAppletMgr instance. Dim oCPAppletMgr Set oCPAppletMgr = CreateObject("CPApplet.CPAppletMgr") ' Get the available ClientActions object. Dim oClientActions Set oClientActions = oCPAppletMgr.GetClientActions() ' Loop through the available client actions. Run the matching client action when it is found. Dim oClientAction For Each oClientAction In oClientActions If oClientAction.Name = actionNameToRun Then oClientAction.PerformAction End If Next ' Wait for 3 minutes for scan completion before exiting script wscript.sleep(180000)
Recently I ran into a problem installing the SCCM client on some Windows Server 2008 R2 systems. In digging through client.msi.log, I found errors 0×80004005 and 1603. Steve Schofield, Microsoft MVP for IIS, discovered the problem was with the client install was, for some reason, performing IIS checks on anonymous authentication. If the authentication is configured to use Application Pool Identity, which was a new feature in IIS 7, then the install will fail. The workaround is simply to switch to using IUSR, install the client, and switch back to the Application Pool Identity.
This successfully resolved my issues on a dozen R2 servers! Thank you Steve!!
The original post:
More thorough explanation:
For those whom need to add language packs to a Win7 image build/deployment, but only have SCCM infrastructure (without MDT integration), a TechNet forum posting gives the answer (which I’ve posted below).
- Create a package and copy each lp.cab file into the root (Just rename each cab so they can all exist in the same folder e.g. de-de.cab for German etc…)
- In your task sequence, after the Setup windows and ConfigMgr step and before you apply any updates (important) add a Run command line step with the following properties:
- Package: The package from step 1
- Disable 64-bit file system redirection: Enabled
- Command Line: cmd.exe /c dism.exe /online /add-package /PackagePath:”%CD%”
This will add all language packs that exist in the package directory to the installed OS. If you need to add more languages later, just drop a CAB file in the package and update it the command line stays the same. This also has the added benefit of only downloading the package once to install all the required languages. If you specify multiple tasks to do this in the task sequence it has to download each one separately which can add some additional overhead to the time to install.
This is just a quick announcement that I am both honored and excited to be a speaker for the SCCM Guru 2012 webcast series! The series is hosted by MyITforum and sponsored by BDNA. My webcast is scheduled for March 28th and the subject is on the power of task sequences. I look forward to presenting!
We purchase and use Dell all-in-ones (Vostro line) as the primary desktop in our organization. The difficulty is that, as consumer hardware, the model can be modified or discontinued at any time without prior notice. Needless to say it creates headaches from time-to-time. Recently the Vostro 360 hardware was changed, resulting in the need for new drivers. Within my SCCM task sequences, I have the install of drivers (within the full OS) limited based upon the name of the model. The challenge with the Vostro 360 is that they maintained the same exact model name, but had different hardware configurations. What I found was a main difference between the two types was the Bluetooth hardware ID. So in addition to querying the model, I added a new query for the Bluetooth hardware.
The point of this post isn’t so much about the Vostro, but more about how I used Win32_PnPEntity to differentiate the two models so that the old config would get one set of drivers and the new config would get the other set of drivers. In the driver install package step for the task sequence, simply click on the Options tab and add a WMI Query action with the following code:
Select * from Win32_PnPEntity where DeviceID like 'USB\\VID_0CF3&PID_3002%'
Ran into an interesting situation with an image build. I created a custom Office 2010 SP1 install using the OCT. During execution of my image build task sequence, Software Updates was not detecting any of the updates for Office. Further diagnosis revealed that the OCT-built install did not put its “hooks” into the Windows Update Agent, therefore neither the SUP or Microsoft Updates could detect for Office updates. (Side note: once the image was sysprepped, captured, and added into a deployment task sequence, the updates were suddenly available and installed.)
While the cause as to why an OCT-built Office 2010 SP1 install prohibits installation of updates has not been found yet, there is a workaround to run a script that forces Microsoft Update (e.g. WUA) to receive updates for “other products”. By executing the following VBScript after installing Office, SCCM Software Updates will then be able to install the updates during the image build task sequence. The original code is from a TechNet blog post, I just added some extra logging for troubleshooting. Also, if your TS advertisement is configured to “run from server”, then the script will cause the TS to fail. To get past this, simply copy the script locally first then execute it from that location.
Const ForAppending = 8 Set oFSO = CreateObject ("Scripting.FileSystemObject") Set oLogFile = oFSO.OpenTextFile ("C:\ConfigOfficeUpdates.txt", ForAppending, True) oLogFile.WriteLine "Starting execution of VBScript to configure Office to use Microsoft Updates" Set ServiceManager = CreateObject("Microsoft.Update.ServiceManager") ServiceManager.ClientApplicationID = "My App" ' add the Microsoft Update Service by GUID Set NewUpdateService = ServiceManager.AddService2("7971f918-a847-4430-9279-4a52d1efe18d",7,"") oLogFile.WriteLine "Script completed successfully" wscript.Quit(oLogFile.Close)
When I set out to blog my experiences with SCCM and engineering the desktop environment, I expected it to help only a few others whom searched hard for a solution over the Internet. I didn’t anticipate how widely used it would become. In just under 3 years, the blog has surpassed 100,000 site visits! More honoring though has been when other SCCM folk throughout the industry have told me in person how my blog has helped them. Even someone I’ve befriended during my tenure at the Microsoft Management Summit, was surprised and excited when he discovered that I had a blog and that I was this “t3chn1ck”!
Here’s to the next 100,000 visits – cheers, and thanks for reading!