Did SMS 2003 SP3 break Netmeeting?
This has been a hot topic in the forums recently, and Brian Huneycutt (Microsoft) has come up with the definitive answer.
From Brian…
Thanks Rod, I had not heard of that post; if so I would have sent out some details sooner as I happen to be very familiar with this particular issue.
The very short version: There will be an SMS client side hotfix to address this.
-------------------------
dnguyen303 covered some of the technical details already in the forum posting, there have been additional updates since then.
There will be a KB article on this, but that article won’t be live for at least a few weeks yet.
As a result, and given the scale/interest, I’ll try to cover everything here in one very long winded email designed to address most all the related questions (we’ll see how I do J ).
I’ll work to get this information up to the SMS/MOM supportability blog either today or early next week. We will post the KB article number there once it is live.
http://blogs.technet.com/smsandmom/default.aspx
You all know ordinarily we don’t typically send out as much detail for a given issue.
Usually there really isn’t all that much to cover, but circumstances are such that I’m able to send this out today so here goes:
Issue / Background
- The SP3 client now backs up its Signing and Encryption certificates to the local machine personal cert store.
- This is required to have our certs persist an OS upgrade from XP to Vista. I don’t have all the gory details as to why they need to survive the upgrade handy, so for now suffice it to say we need them to. I’ll get more into the KB.
- This new behavior hasn’t been clearly documented elsewhere, although I don’t think anyone was of the opinion that it was really that significant. Little did we know…
- NetMeeting Remote Desktop Sharing (all other aspects of NetMeeting are unaffected) is written to grab the first certificate it finds in the personal certificate store thinking it can be used for Client Authentication. Now that certificate happens to be for SMS.
- Our certificates aren’t intended for Client Auth, and thus Remote Desktop Sharing (RDS) doesn’t work. The service will stay paused, and even when started it isn’t really enabled. Trying to activate it just doesn’t do anything.
Workaround
- Immediate term workaround is to just delete the SMS certs from the personal certificate store prior to starting RDS.
That can be done with some of the steps in the forum post, or with certutil.exe using:
certutil –delstore My SMS
- The workaround above has no ill side effect for SMS and allows RDS to start functioning. In some cases you may need to restart conf.exe and mnmsrvc.exe – the Remote Desktop Service – first. Just don’t restart CCMExec at that time…
- The downside to the above is that it requires admin rights, and would need to be executed prior to starting up any RDS session.
This is because as of today CCMExec will actually recopy the certificates back to the personal store on startup.
- I suspect you can use PSExec to execute the above but haven’t tested that myself.
- Other workarounds, such as issuing a certificate that could be used for Client Auth, and numerous other options, have not worked reliably.
- Other remote control / connection tools such as SMS Remote Control, Remote Desktop (for XP and up), or 3rd party remote control tools are all unaffected by this.
Resolution, if you’ve made it this far without dozing off yet:
* Consider this hot off the presses, to the extent that some of you with open support cases in regards to this issue likely have not have received this message yet.
- The plan for right now ~subject to further code review and testing~ is to release a code change for the SMS client that will allow for disabling this certificate backup process via a registry key.
Once the client side hotfix is applied, the default for Win2K machines will be to not back up the certificates, and remove them from the personal store if present.
This can optionally be set for all clients as well, so this fix will effectively cover all operating systems.
Should the planned release change from that significantly I will make sure to get an update out to the community.
Fix related administrivia / more background for the community
When will it be ready? At a minimum expect a few weeks yet as we are very early in the process.
The supportability blog will be updated either once the fix is available, or once we are at the point of giving a firmer ETA.
Will there be a charge for the hotfix?
No – this is a fix being made to SMS 2003, which is still covered in standard support. Earlier forum posts related to charging for the hotfix related to approaching this from the NetMeeting side, specifically for Windows 2000 clients.
Will the hotfix be on the new self help hotfix download page? Probably, will post that to the KB & blog once it’s known for certain. That page for reference is: https://support.microsoft.com/contactus2/emailcontact.aspx?scid=sw;en;1410&WS=hotfix
Why isn’t there a NetMeeting fix being released, isn’t this really a NetMeeting issue?
Yes it is, but to do so requires operating system specific releases.
For Windows 2000, which is where the majority of the impact is, that means customers would need one of the extended hotfix support agreements that allows for the possibility to pay for a hotfix. I don’t have much exposure to how that piece works, but our support lifecycle page has some info here: http://support.microsoft.com/lifecycle
For XP and above, there were simply too many workarounds available – when compared to the overall impact of the problem. Remote Desktop/Remote Assistance/Remote Control can for newer OS’s fill the same need that we were hearing NetMeeting RDS was used for. Combine that with the ability to delete the certificates as needed.
However given all of the OS info above, we still saw the need for more effective relief for our customers.
As a result we’re taking the change from the SMS side to get things back in order again.
That should cover it all I believe, and as noted we’ll get the supportability blog updated with this, and more information as it is available.
Thank you all,
Brian Huneycutt