Windows Live Messenger fails to sign-in from a Windows 7 machine

As I have been rolling out Windows 7 test machines in my organization I have noticed that once in a while Windows Live Messenger would refuse to sign-in. If you were to use the same account on a Windows XP machine or another Windows 7 machine it would sign-in without issue. The majority of our applications have been packaged and pushed via SMS so the install is consistent on all workstations. There seemed to be no rhyme or reason why Messenger would refuse to sign-in from some Windows 7 workstations. After much searching we found a blog post (http://dreamlayers.blogspot.com/2009/12/windows-7-cant-always-automatically.html) about an issue with Windows 7 and root certificates. It seems that some Windows 7 machines fail to update their root certificate automatically which in turn can cause Windows Messenger to fail when you try and sign-in. To resolve this issue download and install the latest root certificate update from Microsoft. (http://download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe) After the update Messenger shouldn’t have any issues signing in.

Troubleshooting ITMU for SMS 2003

Recently my primary SMS server stopped downloading the wsusscn2.cab file from Microsoft’s update site. Without the updated cab file your client machines won’t be scanned for the latest vulnerabilities. I was fairly certain it had to do with a recent firewall upgrade project - with the upgrade our security team also disabled anonymous access on our proxy servers. The PatchDownloader.log file confirmed this:

Download http://go.microsoft.com/fwlink/?LinkID=74689 to C:\WINDOWS\TEMP\wsusscn2.cab returns 403
HttpSendRequest failed HTTP_STATUS_FORBIDDEN or HTTP_STATUS_DENIED


Microsoft has published a knowledgebase article on this issue (http://support.microsoft.com/kb/922365) and how to give the Patchdownloader utility user credentials. To assign credentials open a cmd prompt and browse to SMS\Bin\I386\000004xx\ then run patchdownloader.exe with the following syntax:

Patchdownloader /s:ServerName[:Port] /u:Domain\Username

You will then be prompted for the password of the account that you are trying to assign to the Patchdownloader utility. Now re-run you Sync Tool advertisement on your site server and monitor your patchdownloader.log file with a utility like Trace32 to confirm that everything is working properly.

Windows 7 SP1

Rumours are starting to surface about Microsoft dropping Service Pack 1 for Windows 7 in Q4 2010. Microsoft won’t confirm these reports but they do have a pretty well established product lifecycle for Windows. It took them just 14 months to release Service Pack 1 for Vista so a Q4 2010 Windows 7 Service Pack 1 release seems to be a probable timeframe. Granted Windows 7 has had strong adoption rate numbers but many corporations out there will wait until SP1 is released to start their migration activities. So SP1 may be less about major fixes or performance boosts and more about selling the corporate customer on Windows 7.

Removing Multiple Drivers From SCCM 2007

This past week I needed to remove multiple drivers from SCCM and replace them with updated versions. The only way to do this via the console is one by one. This probably isn’t a big deal if you only have a couple of different platforms however once you start getting into double digits it gets time consuming. You can disable multiple drivers at once but not delete – hopefully this was just a miss by Microsoft and will be resolved in upcoming versions of SCCM. Luckily I found a post by Rod Trent (http://myitforum.com/cs2/blogs/rtrent/archive/2008/11/12/script-to-delete-drivers.aspx) in which he has provided a script that will delete all disabled drivers. This is very handy if you want to delete some drivers but not all. (Most likely scenario for SCCM administrators) Anyway I ended up running this script from my primary site server and within minutes all of my disabled drivers had been removed.

' Connect to the SMS namespace

siteNamespace = GetSiteNamespace()

SET objWMIService = GetObject( "winmgmts:{impersonationLevel=impersonate}!"_
&siteNamespace)

SET drivers = objWMIService.ExecQuery("SELECT * From SMS_Driver")

numDriversDeleted = 0

' Process the results

FOR EACH driver in drivers

IF driver.IsEnabled = 0 THEN
driver.Delete_
numDriversDeleted = numDriversDeleted +1
END IF

NEXT

WScript.Echo "Successfully deleted "&numDriversDeleted&" drivers."
'
' Utility function to search for the site namespace
'
FUNCTION GetSiteNamespace()
' Find SMS Provider
SET objSMSNamespace = GetObject("winmgmts:{impersonationLevel="&_
"impersonate}!\\.\root\sms")
SET results = objSMSNamespace.ExecQuery("SELECT * From "&_
"SMS_ProviderLocation WHERE ProviderForLocalSite = true")

' Process the results

FOR EACH r in results
namespacePath = r.NamespacePath

NEXT

' Fail if we did not find the site

IF namespacePath = "" THEN
WScript.Echo "Failed to locate SMS provider."
WScript.Quit 1
END IF

' Return

GetSiteNamespace = namespacePath

END FUNCTION

Update: This issue has been resolved in Confg Mgr SP2

MMS 2010 Here I Come...

Well it’s been three years in the making but I’m finally going to get a chance to attend the Microsoft Management Summit. I’ve only been looking after our SMS environment for just about three years now. So two years ago , by the time that I found out about MMS it had already taken place and then last year our training / conference budget was axed – not surprised. Besides last year all non-essential projects were shut down due to a few core business initiatives so a move to SCCM was out of the question. What a difference a year makes. We have already started our SMS – SCCM migration plus we a few other core client-side projects in the works so the timing of MMS couldn’t be better.

http://www.mms-2010.com/public/home.aspx