There were several great questions asked during or directly after the System Center 2012 event that we did in Dallas on October 26th (#SCOM #SCCM #SCSM). I’ve been gathering answers from our team (ok, mostly I bugged Chris Nackers because most of these were about Configuration Manager), and here’s what we have:


Q: MDT 2012 – Any word on where this is at and when it will be available?

[Chris Nackers] Beta 2 should be released shortly, MDT will have GA after ConfigMgr, it will not release before ConfigMgr

Q: Configuration Manager 2012 – Does it have dashboards?

[Chris Nackers] No dashboards, all reporting is SRS based

Q: Configuration Manager 2012 – what is the Exchange connector and what does it do?

[Chris Nackers] Allows for the management of mobile devices through ActiveSync

[Chris Nackers]

Q; Configuration Manager 2012 – Is there anything we need to do before going to ConfigMgr 2012?

[Chris Nackers] Side by side migration, where we “pull” across objects, just need a healthy 2007 hierarchy to pull data from

Q: Orchestrator – Can we do any form of role based security access?

[Cameron Fuller] I’m not seeing any form of role based security access available in Orchestrator

Q: Operations Manager 2012 – Can we use pools to put a server into Maintenance Mode?

[Cameron Fuller] I am not seeing any way to use a pool to put servers into maintenance mode. The existing tools appears to reference the RMS ( as an example) which implies that the RMS emulator would be the system which would be specified to put servers into maintenance mode. There are some cool maintenance mode changes (discussed here) but it doesn’t look like pools will assist here.

Q: Connectors versus Orchestrator – What is a connector (Service Manager, Operations Manager, Configuration Manager) and when would we want to use a connector instead of Orchestrator?

[Daniel Ruiz] A connector is a component that allows SCSM to populate CI data into the SCSM database. By using all 3 connectors (AD, SCSM, SCOM-CI) a central repository of information is achieved thereby increasing root cause analysis capabilities. The CI data also allows for the creation of workflows that target specific CI data and scenarios. In my opinion there is no connector vs. orchestrator issue. Orchestrator would be used in conjunction with the connectors to allow for the creation or runbooks and automation workflows.

[Cameron Fuller] We have connected Management Groups in OpsMgr but that should not be relevant to this discussion. The Exchange Connector in Configuration Manager is discussed above. My thought on this as a best practice is if the in-the-box connector does what you need – use that. If not, use an Orchestrator workflow.