KB 841619 – when you can’t connect to SMS from an mmc console on a desktop
Here’s one that pisses me off royally, and another one that Microsoft seem unable to prove exists. At least there’s an answer though… Basically the scenario is: you give delegated access to SMS for a helpdesk user so they can provide remote assistance and diagnostics to users. You install the SMS console on their machine and when you connect and try to view the collections the egg-timer pops up, and you wait, and you wait, and then you get no collections! Zip, Nadda. Not a sausage. Eh!?
Well it seems to be caused by one things – XP Service Pack 2. The answer? Relax your security. Well done Microsoft…
Here’s the short of what to do to get around the problem:
1. Make sure the delegated user’s firewall is either off (if your in an Enterprise it probably will be off anyway) or make sure that tcp port 135 is open for your network, and %windir%system32wbemunsecapp.exe is added to the allowed applications list.
2. Run up dcomcnfg.exe, browse to “My Computer” in the console, choose properties of My Computer and choose the COM Security pane, and in the Access Permissions box click “Edit Limits…” and allow ANONYMOUS LOGON the Remote Access permission.
3. Now restart.
That should fix the issue. If it doesn’t then the user probably doesn’t have the right permissions in SMS, or the settings haven’t taken properly on the machine.
If you’re sure those settings taken then check that the user is a member of any groups that are in the “Distributed COM Users” local group on your SMS server/s.
Here’s some info from Rick Jones explaining how to make some custom collections in SMS which let you find out EXACTLY what machines have got the SMS client installed. Anyone who uses SMS with thousands of machines will understand why this is handy!
Really really usesful this one. All praise Rick Jones! I wish I’d found this sooner.
Since SilverLight 1.0 has been released I thought it best if I deployed this to all the machines I manage. Naturally it was quite early after the release that I tried to do this and Microsoft hadn’t exactly been helpful with how to do it. So I worked it out 🙂 Not that hard as usual.
Here’s what you do:
1. Get the .exe [link is for version 1.0.20816.0]
2. Unpack the .exe with the command: “Silverlight 1.0.exe” /x and put the files in an empty folder, eg. c:tempsilverlight
The files you’ve unpacked will include an .msi and an .msp – we need both of those as the .msi seems to do nothing much more than put the prog in Add/Remove Progs.
4. Now create your package in SMS, or modify your script, and use the following command from within a .cmd script file:
msiexec /qn /norestart /i “%~dp0silverlight.msi” /update “%~dp0silverlight.msp” ALLUSERS=2 (the %~dp0 command here is to put the path in to allow the update part of the command to work, as msiexec doesn’t seem to like /update usage when you don’t put the path to the file in)
5. Change the settings for the package so it runs from a drive letter and runs whether or not a user is logged in. You need a drive letter because you’re running a .cmd and these rarely work properly when run from a unc path.
That will install SilverLight 1.0 for all users of the computer silently and without rebooting the machines. It might need a reboot if IE is in use when the install starts so best to stop that too. It’ll shove its plug-in into Firefox if it’s installed as well which is handy.
One thing of note is that like Flash, SilverLight will try to install updates automatically. We probably don’t want that (I certainly don’t) and fortunately there’s a reg key to stop this happening… I made a group policy template for this one so it was set automatically.
Updated on 2007-12-06…
Since doing all this Microsoft did release a needlessly long document on how to do all this, all they really needed to say was: the quiet install option is… “/q” OK, whatever. Here’s their document: http://download.microsoft.com/download/7/8/d/78da8ec9-8801-42e5-89e5-3809386f1316/Silverlight%20Deployment%20Guide.doc
Yet again, the usual annoyance with bloody Server 2003 SP1…argh!!! And now we have SP2 to play with too…what’s this one going to screw up I wonder…
If you’ve upgraded to 2003 SP1 on a server that has SMS2003, any delegated users that use the SMS console (e.g. for the remote control tools) will lose connectivity. See KB913000 article for assistance. It gets you to add a user or group to the ‘Distributed COM Users’ local group. God I should have known that one by now…
I found out a bit more about ‘why’ that makes it work and found the following article where you can give a security group remote launch and activation permissions.