From time to time patch installations will fail during our OS deployment process leaving the workstation not fully patched. Once a machine has finished imaging someone from the deployment group will usually do a spot check and connect to Windows Update just to ensure that the workstation is fully patched. Last week I started to notice that many of the new Windows 7 workstations would not connect to Windows Update and get the following error:
An error occurred while checking for new updates for your computer.
Error(s) found:
Code 80072F8F
Checking online I found a Microsoft article that explained that this error usually results from a time mismatch between your machine and the Windows Update servers. However, these workstations were members of our domain and all of the time settings were correct. I found another post referencing root cert problems and the Windows Update error 80072F8F which reminded me of my post about Windows 7 failing to update its root certificates and causing Windows Live Messenger sign-in to fail. After updating to the latest root certificates (KB931125) Windows Update connected just fine.
Monday, February 14, 2011
Monday, January 31, 2011
Office 2010 and the Dell OMCI client
When I first started to deploy Windows 7 using ConfigMgr our task sequence included Office 2010 Professional Plus. Early on I noticed that during the deployment Office 2010 would never get installed yet all other application were. All of my image development is done using Hyper-V (which worked without issue) and this only occurred on physical machines. After going over countless ConfigMgr logs, recreating task sequences and internet searches I found a random post mentioning that the Dell OMCI client changes permissions on two folders:
C:\Windows\System32\winevt
C:\Windows\System32\winevt\Logs
The permission change on these two folders can also prevent Office 2010 from installing. Once I moved the Dell OMCI install to the end of the task sequence so that it installed after Office 2010 I had no issues.
C:\Windows\System32\winevt
C:\Windows\System32\winevt\Logs
The permission change on these two folders can also prevent Office 2010 from installing. Once I moved the Dell OMCI install to the end of the task sequence so that it installed after Office 2010 I had no issues.
Wednesday, September 22, 2010
Problems accessing file shares from Server 2008 R2 using the SMB protocol
My current ConfigMgr infrastructure includes distribution points scattered around North America and Caribbean. We are forced to use a simple file share as these devices don’t support IIS so packages are replicated using the SMB protocol. These remote devices were first used for our SMS environment where my primary site server was running Windows Server 2003 and I had very few problems. Since I have moved to ConfigMgr, where my primary site server is running Windows Server 2008 R2, I have had nothing but grief. Most of the time my site will fail to establish a connection to my remote devices until I reboot the server. The reboot is a temporary fix as the connection problem will resurface shortly. I’m able to connect to the share from other machines and my connection account is a local admin on the distribution points. I can ping the remote device from the site server but when I browse to the share I get the following error:
Error code: 0x80070035
The network path was not found.
After a little digging I came across Microsoft article KB2194664 referencing these exact symptoms. Essentially the Mrxsmb10.sys driver specifies a logon ID the first time that a connection is established to a remote share using the SMB protocol. The logon ID and the name of the server are saved in a server entry of the SMB Redirector. However, the Mrxsmb10.sys driver does not update the logon ID after the initial logon. Any attempt thereafter to use the name from the first connection will fail regardless of the user name. The hotfix referenced on the KB article will resolve this issue and has helped immensely in my environment.
Error code: 0x80070035
The network path was not found.
After a little digging I came across Microsoft article KB2194664 referencing these exact symptoms. Essentially the Mrxsmb10.sys driver specifies a logon ID the first time that a connection is established to a remote share using the SMB protocol. The logon ID and the name of the server are saved in a server entry of the SMB Redirector. However, the Mrxsmb10.sys driver does not update the logon ID after the initial logon. Any attempt thereafter to use the name from the first connection will fail regardless of the user name. The hotfix referenced on the KB article will resolve this issue and has helped immensely in my environment.
Saturday, September 18, 2010
MP needs to reload the hardware inventory class mapping table warnings
Recently during a ConfigMgr upgrade my SMS_MP_CONTROL_MANAGER was littered with the following warnings:
MP needs to reload the hardware inventory class mapping table when processing Hardware inventory. The MP hardware inventory manager cannot find a WMI class definition in the mapping table when processing a report. This should only happen if new definitions beyond those known to the SMS are added to the collected classes.
Possible cause: Inconsistent way the new definitions have been introduced.
Solution: Check that the mapping tables contain the information consistent with the hardware definition tables and that the definitions have been propagated properly.
Possible cause: Corruption of the data base.
Solution: Check the consistency of the data base.
After a little research I found that this is usually caused by clients that have a version of SMS.Def.mof that is out of sync from the version found on the site server. These messages should only happen once per client as they pull down and update the version of their SMS.Def.mof file. In my case I was upgrading from SMS 2003 to ConfigMgr and as more and more clients updated their SMS_Def.mof file these messages started to reside. If you continue to get these messages it would be a good idea to engage Microsoft CSS.
MP needs to reload the hardware inventory class mapping table when processing Hardware inventory. The MP hardware inventory manager cannot find a WMI class definition in the mapping table when processing a report. This should only happen if new definitions beyond those known to the SMS are added to the collected classes.
Possible cause: Inconsistent way the new definitions have been introduced.
Solution: Check that the mapping tables contain the information consistent with the hardware definition tables and that the definitions have been propagated properly.
Possible cause: Corruption of the data base.
Solution: Check the consistency of the data base.
After a little research I found that this is usually caused by clients that have a version of SMS.Def.mof that is out of sync from the version found on the site server. These messages should only happen once per client as they pull down and update the version of their SMS.Def.mof file. In my case I was upgrading from SMS 2003 to ConfigMgr and as more and more clients updated their SMS_Def.mof file these messages started to reside. If you continue to get these messages it would be a good idea to engage Microsoft CSS.
Monday, September 13, 2010
Clearing padlocks on SMS or ConfigMgr objects
During an in place migration from SMS 2003 to ConfigMgr a best practice is to build a new SMS site and attach it as a child so that you can replicate all of your objects, break the parent – child relationship and then upgrade to ConfigMgr. At that point you can decide if everything upgraded successfully, the new site is healthy, all objects have been replicated and then you can migrate your clients to the new ConfigMgr site. For more details on this migration strategy check out Kim Oppalfens’ blog post on how to transition from SMS 2003 to ConfigMgr 2007.
When you have a parent – child relationship any collection that is being replicated from the parent site will be locked and can be identified by the little gold padlock icon under the collection node. Now once that relationship is broken the objects that were being replicated will remain and the padlock should then disappear allowing you change that object’s properties. Once in while some of the padlocks will remain after the relationship is broken leaving the object locked and you unable to do anything with that object.
Sometimes the only way to unlock these objects is run a couple of commands in against your SQL database as outlined in Ed Aldrich's article on myITforum.com.
When you have a parent – child relationship any collection that is being replicated from the parent site will be locked and can be identified by the little gold padlock icon under the collection node. Now once that relationship is broken the objects that were being replicated will remain and the padlock should then disappear allowing you change that object’s properties. Once in while some of the padlocks will remain after the relationship is broken leaving the object locked and you unable to do anything with that object.
Sometimes the only way to unlock these objects is run a couple of commands in against your SQL database as outlined in Ed Aldrich's article on myITforum.com.
- Stop the SMS_Executive service
- Stop the SMS_Site_Component_Manager service
- Stop the Windows Management Instrumentation service
- Open Microsoft SQL Server Management Studio and connect to your site database
- Identify the collection ID that still has the padlock icon
- Right-click the database and select New Query
- Type select * from collections and click Execute (Red exclamation point on the SQL Editor toolbar)
- Type update collections set flags='18' where siteID='your collection ID' (Note all collection flags should be either 17 or 18)
- Restart your WMI, SMS_Executive and SMS_Site_Component services
- Open your SMS or ConfigMgr console and the padlock icon should be gone from the collection in question
Subscribe to:
Posts (Atom)
