I’ve been running IE 9 since the early beta versions were released and I must say it's pretty solid. IE 9 offers a cleaned up interface which by default removes the status bar, favourites bar an many of the command buttons. Microsoft still gives you the option to add these features back on but I like the fact that they are trying to make the interface as clean as possible. Some of the nicest features includes a download bar that allows you to manage your downloads independently from your browsing session, the "new tab" window now includes a list of your most popular sites and the ability to reopen closed tabs but I think that the nicest feature is that Microsoft has finally integrated the address bar and the search bar – much like Google’s Chrome. However, if you're still running Windows XP you're out of luck as IE 9 is currently only available for Windows Vista or Windows 7 and it doesn't look like Microsoft is going to change their stance. Try it today…
http://windows.microsoft.com/ie9
Monday, February 21, 2011
Monday, February 14, 2011
Windows Update Error Code 80072F8F
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.
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.
Labels:
ConfigMgr / SCCM,
OS Deployment,
Windows 7
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.
Labels:
Dell OMCI,
Office 2010,
Windows 7
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.
Labels:
ConfigMgr / SCCM,
Windows 2008 R2
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.
Labels:
ConfigMgr / SCCM,
SMS 2003
Subscribe to:
Posts (Atom)