In a recent build and capture (b&c) task sequence for ConfigMgr 2012 R2 that I was helping a customer with, I decided it was worthwhile to list the top things that can be overlooked. If these are done prior to beginning the process, then it can help to shorten and troubleshooting time involved. Also, be sure to see my tips for installing apps during OSD.
- Create an IP address range for content boundaries. When doing a b&c, it is a best practice to not join the system to the domain. So if AD Sites are used for the boundaries, then content cannot be found. To workaround this, add a IP address range boundary for the subnet of the virtual system.
- In task sequence step “Setup Windows and Configuration Manager”, include entry “SMSMP=SiteMPServerFQDN”. Example FQDN: CM1.contoso.com.
- Include installation of the latest cumulative update that is installed on the primary site. The easiest trick for ensuring the latest CU is installed during OSD is to do:
- Copy the hotfix install package from “C:\Program Files\Microsoft Configuration Manager\hotfix\KBxxxxxx\Client\” into “C:\Program Files\Microsoft Configuration Manager\Client\hotfix\KBxxxxxx\”.
- In the task sequence step “Setup Windows and Configuration Manager”, include the line “PATCH=’%_SMSTSMDataPath%\OSD\PkgID\hotfix\KBxxxxxx\x64\patchKBinstallname.msp’. Note that the path x64/i386 will need to be updated based upon the target OS.
- ConfigMgr boot media (.iso, USB, etc.) has been configured to allow unknown computers.
- Use the offline servicing functionality to pre-inject / install any Windows and .NET Framework 3.5.x security updates. Doing this to the original Windows image that was imported into the primary site will reduce the deployment time for the b&c. Note that if you are deploying Win7 Hotfix Rollup 1 (KB2775511), it can be helpful to add it into the list for Software Updates (see http://blogs.technet.com/b/brandonlinton/archive/2013/03/13/how-to-deploy-phantom-updates-with-system-center-configuration-manager.aspx).
- Prepare for Software Updates (e.g. MS security updates)
- Use multiple Install Software Updates steps. I like to use one immediately after installing core MS software (newer versions of .NET, MSXML, PowerShell, etc.) and then use two more at the very end of the task sequence.
- Optional: Create a script to which associates Microsoft Office with the Windows update agent so that those patches can be installed.
- Implement fixes and workarounds for installing packages and applications.
- Set additional task sequence variables to prevent “Error 80070002”. This is outlined in a TechNet support tip blog post, but impacts more than just MDT.
- SMSTSDownloadRetryCount = 5
- SMSTSDownloadRetryDelay = 15
- Configure the Windows image to be able to “run from the server”. In this way, the image does not need to download to the disk then finally extract … thereby causing a longer delay and more fragmentation. To do this:
- On the properties of the image, go to the Data Access tab and select the option to “copy the content in this package to a package share on distribution points”.
- In the task sequence’s step for Apply Operating System, go to the Options tab and select “Access content directly from the distribution point”.
- Configure the distribution point to allow anonymous connections.
In general the above items should help you to be more successful when doing an OSD image b&c. So that it’s not left unsaid, the below items could also prove useful.
- Setup the Network Access Account for the ConfigMgr primary site. For security, ensure that the account is a low rights domain user with a complex password and not an account with extended access rights to any systems on the network.
- Deploy the task sequence to All Unknown Computers. In this way an record of the ConfigMgr client will not need to be created first and added into a special collection.
I recently had a request from a customer to rename their PCs during an in-place upgrade of WinXP to Win7. I’ve put together some custom scripts to detect the particular qualifying conditions for when the PC needs to be renamed, and these scripts work just fine (this is an upcoming blog post).
The problem that I ran into was that after completion of the task sequence, the CM07 client was unable to register with the site server. Thereby it wouldn’t receive policies and did not operate. The client’s ClientIDManagerStartup.log showed “Error initializing client registration (0x80040222)”. As part of my troubleshooting, I was able to “fix” the client by deleting the old computer record instance and the generate a new GUID on the client.
Credit to one of my colleagues who was able to identify the scenario when I had overlooked it. The real problem was that since the PC was being renamed, a Conflicting Record was being created since both the old and new instance had the same hardware ID information. There are two ways to resolve this situation:
- Manually resolve the conflicting records
- Configure the site to automatically resolve the conflicting records
Option 2 is the most desirable since you can set it and forget it….so that’s we did!
Ran into a situation where all CM07 clients at a particular site were not installed/active within the ConfigMgr primary site. Digging into the ccmexec.log file on the clients, errors were generated repeatedly with message “Failed in WinHttpSendRequest API 0x2ee7”. In this particular scenario, I discovered that the client was attempting to communicate with the MP when the error occurred…and that the server’s name was incorrect. So instead of trying to reach ServerA01, it was trying to reach ServerA (note the missing zero+one at the end of the name). Turns out that when the Secondary Site was set up, whomever had created the site mistyped the name.
To fix this, the following needed to happen for me to eventually get this to work.
- Update the Secondary Site’s specified FQDN to be the correct name as ServerA01
- Uninstall the proxy MP on the secondary
- Manually delete the SMS-MP records in the Systems Management container. I had to do this because for some reason the site didn’t have the correct permissions, even though it really did.
- Reinstall the proxy MP
- Regenerate new GUIDs for the clients at the site (I used the SCCM Client Center tool to perform this). I had to generate the new GUIDs because they were not receiving the corrected FQDN server name on their own.
And within minutes, all was clear and clients were functioning again!
On a recent upgrade project of ConfigMgr 2007 to 2012, the company I was assisting with the upgrade had previously deployed a group policy to enforce the client assignment to the 2007 site code. However, simply removing the GPO could not correct the situation as the value was “tattooed” into the registry. So as part of the ConfigMgr client upgrade, I included the below script to revoke the registry key.
' *********************************************************** ' This script was created by <a href="https://t3chn1ck.wordpress.com/">https://t3chn1ck.wordpress.com</a> to ' delete the following registry value. The value will prevent ' the abilityof anSCCM client to become reassigned to the new ' ConfigMgr 2012 site. ' HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Mobile Client\ ' GPRequestedSiteAssignmentCode (REG_SZ) = "" ' *********************************************************** Option Explicit Const HKLM = &H80000002 Const sRegKey = "SOFTWARE\Microsoft\SMS\Mobile Client" Const sRegValueName = "GPRequestedSiteAssignmentCode" Dim oReg, iReturnValue Set oReg = GetObject("winmgmts:\\.\root\default:StdRegProv") iReturnValue = oReg.SetStringValue (HKLM, sRegKey, sRegValueName, "") wscript.quit iReturnValue
I ran into an interesting issue with a SCCM implementation in an environment that utilizes Cisco NAC to protect their system resources from unauthorized devices. One of the goals of the implementation was to ensure the SCCM clients could still function when no user was logged into Windows, thus NAC agent not being authenticated with the production VLAN. In order to accomplish this, ports used by SCCM needed to be opened, allowed, and unrestricted to the SCCM servers.
The issue that we found was when the computer was on the “dirty” VLAN, the SCCM client would switch from being an Intranet client to an Internet client. Furthermore, the client’s LocationServices log showed that it was failing to locate the MP from AD and the SLP from AD.
Using a network monitoring tool called WireShark, we identified that the client was trying to communicate with AD on TCP port 3268. This is a normal port used by AD for LDAP. Checking into the configuration of NAC, it was certainly not allowing communication over that port. As soon as that was allowed, the SCCM client immediately began functioning to download software updates and SWD packages. Who knows whatever else was fixed through this discovery…
You may be asking, what does IIS bindings have to do with SCCM software updates. Well, let me tell you lol.
I’ve stood up a new SCCM infrastructure including site configuration/roles and deployed a few clients. When testing software updates on a client, software update scan/deployment cycles kept failing. Upon investigation of logs, the scan were failing with “Scan failed with error = 0x80072efd”. Furthermore, reporting showed scan error failure code -2147012867. These errors indicate that the Windows Update Agent could not communicate with the defined source location.
The troubleshooting difficulty is that there are many possibilities of causing this.
- Local GPO “Specify intranet Microsoft update service location”. When using SCCM software updates, the client sets this local GPO on the client pointing to the WSUS location. In my case this wasn’t it.
- Windows Firewall blocking the ports used by WSUS, on either the client or server. In my case this wasn’t it.
- A proxy or bad winhttp settings redirecting the traffic incorrectly from client to server. In my case this wasn’t it.
- Various other things.
I believed that I had reached the end of the Internet at this point when finally I came across a posting on WindowsNoob that steered me in the right direction. To fix a different technical problem with WSUS conflicting with Symantec Endpoint Protection, I swapped the Software Updates Component from using ports 80/443 to using ports 8530/8531. I guess with this change, SCCM didn’t automagically configure the default website in IIS bindings to listen for requests on the newly defined port.
So to resolve the issue, I did the following:
- Open IIS Manager
- Right-click on the default website and select “Edit Bindings”
- Add port 8530 as an IIS binding….and voila it works.
Came across this very useful article and FAQs about SCCM in a multi-domain or multi-forest scenario.