I've never tried the registry values, but there are command-line switches to rc.exe in 2007 that tell rc.exe which site server (sms provider actually as these are almost always assumed to be the same) to use to check permissions and send auditing info. Just run rc.exe at the command-line. I *think* the same is true for 2012 but from memory it was slightly different.
J From: [email protected] [mailto:[email protected]] On Behalf Of Kim Oppalfens Sent: Thursday, September 19, 2013 7:34 AM To: [email protected] Subject: RE: [mssms] ConfigMgr 2012 SP1 Console Connection Limit Rc.exe actually does deliver auditing even in ConfigMgr 2007. The requirement for this to work is that the AdminUI has to be installed on the machine running rc.exe. Note that there is no requirement for RC.exe to be launched from that same admin ui. My educated guess is that the reason for this is that the adminui saves the siteserver and sitecode you connect to in the registry. IIRC, it actually saves it here, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Identification. And here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ConfigMgr10 So you might get away with just importing those registry keys, and keep on working with rc.exe From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Marcum, John Sent: 18 September 2013 19:54 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] ConfigMgr 2012 SP1 Console Connection Limit I "think" there's a way to audit even if you are not launching the session from the console but I am not sure. I seem to recall reading a blog about how to do that once. I don't think that there is a limit on concurrent sessions but I would not suggest deploying that many consoles. Keeping them updated is a total nightmare. Put it in Citrix instead. Better yet, use something like WebEx or Lync. We just bought Bomgar which seems pretty cool but would likely be expensive for that many users. ________________________________ John Marcum Sr. Desktop Architect Bradley Arant Boult Cummings LLP ________________________________ From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Eric Morrison Sent: Wednesday, September 18, 2013 12:46 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] ConfigMgr 2012 SP1 Console Connection Limit Hello Everyone, I'm currently at a client doing a ConfigMgr 2007 to ConfigMgr 2012 SP1 migration. Currently in their 2007 environment, they use the built-in remote control features of ConfigMgr to connect to different machines throughout the organization for support scenarios and different testing situations. The way they are handling this currently is RC.EXE and the required DLLs sequenced up in an App-V package and made available to all users via RAP (Run Advertised Programs). The only problem with this, is they can't centrally audit who is connecting to what machine, etc. In 2012, they want to be able to do this, so I suggested setting up RBAC for remote tools users and we sequence the new ConfigMgr 2012 SP1 console. They like this idea, but then I found out that they have roughly 1,200 different people that use the remote tools feature to connect to different machines throughout the organization. Apparently the RC.exe workaround will work in 2012 still, but just in case we decide to allow that many people to use the console for remote tools purposes, what is the concurrent connection limit, if any? If there is not a hard limit, are there any guidelines to support a large number of simultaneous connections with the ConfigMgr console? Even though 1,200 people may use this feature, only around 30-50 at any given time will probably be connected. Thanks! Eric Morrison ________________________________ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer. ________________________________ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer.
