IN THIS CHAPTER
Configuration Manager Workspaces
Using Role-Based Administration
The In-Console Alert Experience
Configuration Manager Service Manager
Configuration Manager’s console historically used the Microsoft Management Console (MMC) framework. The console has evolved over the years, receiving little touches to enhance the administrative experience with each product version.
Starting with System Center 2012 Configuration Manager (ConfigMgr), the console utilizes the System Center framework, bringing a fresh and intuitive look to the platform. By building the ConfigMgr console on this common framework, Microsoft aligned the console with the familiar look and feel of the other System Center products. In addition, role-based security controls the console experience, giving each security role a common set of views, tasks, and objects.
The ConfigMgr console is the administrative interface for managing all facets of the ConfigMgr infrastructure, applications, deployments, software updates, monitoring, and users and devices. As a key element of any ConfigMgr environment, the console is also the interface used to maintain the site and hierarchy; you use it to perform daily tasks to manage and configure sites, the site database, and clients and to monitor the status of the hierarchy.
The console sports some very nice features, which this chapter covers in detail. The highlights follow:
Similar operations are grouped together into intuitive, administrative workspaces.
ConfigMgr now has Outlook-style navigation, coupled with context-sensitive ribbon tabs that display only the relevant actions.
Supporting role-based administration (RBA), the console displays only what you have rights to see, removing much of the clutter and confusion often associated with a very busy console.
Search bars in nearly every facet of the console enable instant filtering to narrow down the scope of data to a manageable view.
PowerShell integration allows you to quickly launch a PowerShell command prompt or the Integrated Scripting Environment (ISE) and automatically load the ConfigMgr module for PowerShell.
Temporary nodes help track various objects used in the console, allowing quick reference to objects you have already visited.
Just as in your favorite web browser, a temporary history is available of the areas you have visited while navigating the console, making it easy to go back to a previous view.
In-console alerts bring near-real-time status information, providing light monitoring functionality without requiring you to leave the console.
This chapter describes the core areas of the console and its many features. It also covers console installation and deployment, including console prerequisites, security considerations, and troubleshooting.
As you open the System Center Configuration Manager console, you will notice that it is divided into four main quadrants, reminiscent of previous versions of Outlook:
Navigation
Lists
Detail
Bars
In addition, the console contains functionality that is similar in behavior to Outlook. The Navigation pane and ribbon bar are key elements of Outlook that you will immediately recognize in the ConfigMgr console.
Console panes are areas that are themed to contain certain types of objects. There are three panes in the console, as shown in Figure 8.1:
Navigation: The left side of the console is known as the Navigation pane (sometimes referred to as the WunderBar). The workspaces at the bottom allow you to move quickly between administrative areas, and you can use the folder list at the top to select specific nodes.
List: Depending on the selected node, the List pane on the right side displays charts, dashboards, or lists of objects.
Details: When you select certain items in the List pane, the Details pane dynamically shows additional information about the selected item. Often, the Details pane is broken out into multiple tabs that provide more information.
NOTE: WUNDERBAR TRIVIA
Did you ever wonder where the name WunderBar originated? Before the WunderBar term was used, the Navigation pane was known as the “Combined Outlook Bar and Folder List.” To learn how it got this name, as well as how the ribbon bar got its name, see http://blogs.msdn.com/b/jensenh/archive/2005/10/07/478214.aspx.
The ConfigMgr console also includes three bars, displayed in Figure 8.2:
Ribbon: The ribbon bar, situated along the top of the console, is a context-sensitive list of commands available based on the selected object.
Address: The address bar, shown as in Figure 8.2, shows the node on which the console is currently focused. It is primarily designed to make navigation easier by providing a history of places already visited.
Search: The search bar provides a means of isolating the objects in the List pane by matching them against criteria to help you quickly find information.
The tab on the far-left section of the ribbon bar is referred to as the backstage. The backstage contains a common set of commands that are available no matter where the focus is in the ConfigMgr console, providing a consistent set of commands. As shown in Figure 8.3, the backstage contains the following commands:
Connect to a New Site: Displays the Site Connection dialog box for connecting to a different site server.
Connect via Windows PowerShell: Launches a PowerShell command prompt and loads the ConfigMgr module.
Connect via Windows PowerShell ISE: Launches the PowerShell ISE and loads the ConfigMgr module.
About Configuration Manager: Displays the About System Center Configuration Manager dialog box.
Help: Displays the help file.
Customer Experience Improvement Program: Launches the Customer Experience Improvement Program dialog box, which you can use to enable or disable participation in that program.
Exit: Closes the ConfigMgr console.
The Configuration Manager console has four different workspaces:
Assets and Compliance
Software Library
Monitoring
Administration
Each workspace is designed for a specific purpose, and similar functions are grouped together. When you select a workspace, the Navigation pane displays a particular set of nodes in the folder list. The next sections discuss these four workspaces.
The Assets and Compliance workspace, shown in Figure 8.4, includes collections for managing users and devices. In addition, you can use this workspace to manage user state migration, asset intelligence, and software metering.
You can use this workspace to manage baselines and configuration items for compliance settings. You can also manage endpoint protection policies for configuring antimalware and firewall settings in this workspace.
Following are the main nodes in the Assets and Compliance workspace:
Users
Devices
User Collections
Device Collections
User State Migration
Asset Intelligence
Software Metering
Compliance Settings
Endpoint Protection
All Corporate-owned Devices
The Software Library workspace, shown in Figure 8.5, shows all the elements for managing applications, software updates, and operating system deployments. However, this node is not just about organizing content; it includes other activities, such as managing the global conditions and requirement rules that drive the stateful behavior of applications, managing automatic deployment rules for software updates, and managing task sequences—which provides a means for performing multiple steps on a client system (typically when using Operating System Deployment [OSD]). In addition, when users request applications through Software Center, these approval requests populate the Approval Requests node. You can use this workspace to approve or deny application requests.
You can use this workspace to manage all software updates, including synchronizing software updates and managing automatic deployment rules to update and deploy software updates. All drivers, images, and task sequences that comprise operating system deployments exist in this workspace.
The Software Library workspace has four main nodes:
Application Management
Software Updates
Operating Systems
Windows 10 Servicing
The Monitoring workspace, as the name suggests, monitors information. You can view the status of the ConfigMgr infrastructure (site, component, distribution, replication, and so on) in various nodes. Client health information is also available. When these types of statuses are set for alerting, the alert data populates the Alerts node, enabling you to manage these alerts (by commenting, postponing, disabling, and so on). You can view status information in more ways than just text. This workspace includes diagram views that display status, alert, and configuration data over a hierarchy diagram or geographic view. Figure 8.6 shows a site hierarchy diagram view that graphically shows the status of the hierarchy.
You might typically think of monitoring in terms of alerts and statuses, but the Monitoring workspace contains far more. For example, you can manage reports and create subscriptions from this workspace.
You also manage and execute queries from the Monitoring workspace. Although collections and queries are often viewed as interrelated, it is important to note that they exist in different workspaces in the console.
The following are the main nodes in this workspace:
Alerts
Queries
Reporting
Site Hierarchy
System Status
Deployments
Client Operations
Client Status
Database Replication
Distribution Status
Software Update Point Synchronization Status
Updates and Servicing Status
Security
The Administration workspace, shown in Figure 8.7, contains the nodes necessary for managing the ConfigMgr infrastructure, security, and settings. ConfigMgr infrastructure management consists of tasks such as managing distribution points, site boundaries, resource discoveries, and migration of objects from separate ConfigMgr hierarchies. You can create, assign, and edit custom ConfigMgr client settings in this workspace.
You can use this workspace to add administrative users to System Center Configuration Manager. You can assign new roles, create scopes, and apply permissions. In addition, you can manage certificates used in various components of ConfigMgr in the Administration workspace.
This workspace consists of the following main nodes:
Updates and Servicing
Hierarchy Configuration
Cloud Services
Site Configuration
Client Settings
Security
Distribution Points
Distribution Point Groups
Migration
The ConfigMgr console can be installed as a part of the central administration site (CAS) or primary site server installation. Unlike earlier versions of ConfigMgr, with Current Branch this is a choice and not a requirement. Most organizations do not have a single person manage the administration and operation of ConfigMgr. This is especially true in enterprises where management resides with entire teams.
Regardless of whether administration is by one administrator or a group of administrators scattered around the globe, the authors recommend installing the console locally on the administrator’s desktop.
However, depending on your hierarchy, there could be potential challenges with local console installations. For example, if the hierarchy is designed such that a site database server and SMS provider are not physically near the administrator and WAN latency is an issue, the console may perform poorly as it must retrieve content over a slow link.
You might want to install the console on a server with the SMS provider and allow administrators access to the console over Remote Desktop Services (RDS). The SMS provider can be installed on the ConfigMgr site server, the database server, or an entirely separate server. Installing additional SMS providers in a site distributes the workload and provides high availability for console connections. If bandwidth is a factor, the console could be loaded on the primary site server, allowing administrators to use RDS to manage the site.
Regardless of the number of providers, if the SMS provider is not on the same server as the database server, there will be impacts to console performance from the speed and latency of the connection from the SMS provider to the database.
NOTE: THE ROLE OF THE SMS PROVIDER
When a ConfigMgr console connects to a ConfigMgr site server, it is important to recognize that the console is connecting to the database. To be more specific, the console connects to the SMS provider, a Windows Management Instrumentation (WMI) provider that handles all reads and writes to the site database.
Often those using ConfigMgr are not administrators. For example, help desk staff might use the console as a means to view a device’s configuration data or connect through remote control to assist an end user. In situations such as these, it is far safer and easier to provide a local console than to allow help desk staff to log on to the server directly.
The ConfigMgr console can run on any currently supported Windows operating system, either workstation or server, x86 or x64.
System Center Configuration Manager includes the Prerequisite Checker, which can help determine whether a computer meets the requirements to run the ConfigMgr console. You can find the prereqchk.exe utility located under SMSSETUPBINX64 of the ConfigMgr source files or the %ProgramFiles%Microsoft Configuration Managerinx64 folder of an installed server.
When you run prereqchk.exe with the ADMINUI
switch, it runs through a scan of the specified system to determine if it meets the requirements for installing the console. You run the utility to scan for console prerequisites by issuing the following command:
prereqchk.exe /ADMINUI
After the utility runs, you can find the log of the prerequisite scan in the root of the system drive named ConfigMgrPrereq.log. Following are the required components for the ConfigMgr console:
.NET Framework 4.2 or higher
Microsoft XML Core Services 6.0 (MSXML60)
Windows Remote Management (WinRM) v1.1
For further information about the Prerequisite Checker, see https://docs.microsoft.com/sccm/core/servers/deploy/install/prerequisite-checker.
When all prerequisites are met, you can install the ConfigMgr console by launching the System Center Configuration Manager Setup Wizard. Start the wizard by opening the splash.hta file, found in the root of the installation media.
TIP: LAUNCHING THE CONSOLE INSTALLATION WIZARD WITHOUT THE SETUP WIZARD
It is not necessary to use the System Center Configuration Manager Setup Wizard to install the console, as the console install is now separate from the rest of the product. Navigate to the SMSSETUPBINI386 folder and click consolesetup.exe to launch the console installation program.
To install the console using the System Center Configuration Manager Setup Wizard, perform the following steps:
1. In the Tools and Standalone Components section, click the Install Configuration Manager Console link.
2. The Configuration Manager Console Setup Wizard launches, indicating This Wizard Will Install the Configuration Manager Console. When you are ready, click Next to continue.
3. On the Site Server page, enter the site server fully qualified domain name (FQDN) for the ConfigMgr console to connect to on its first launch. Click Next.
4. The Installation Folder page displays the default path where the installation will occur. Choose the default or select a new path by clicking Browse, and then click Next.
5. On the Ready to Install screen, which displays all settings required for setup, select Back to review or change the settings, if necessary. Then click Install. The Please Wait page appears, showing a progress bar that provides a visual indicator of the installation. The wizard also displays the installation steps on this page.
6. When installation completes, leave the option Start the Configuration Manager Console After You Close the Setup Wizard Is Displayed checked and click Finish to complete the wizard.
In situations in which multiple individuals will manage administration and operation of the ConfigMgr infrastructure, it may be beneficial to automate the console installation.
Before installing the console, verify that the target systems meet the prerequisites identified earlier in this chapter, in the “Installation Prerequisites” section, including the supported platform (though this should not be a problem in most scenarios). The supported method for installing the ConfigMgr console uses the executable consolesetup.exe mentioned in the “Launching the Console Installation Wizard Without the Setup Wizard” tip in the previous section.
The executable accepts the following switches:
/q
: Indicates a silent install of the ConfigMgr console. Requires specifying ENABLESQM
and DEFAULTSITESERVERNAME
.
/uninstall
: Uninstalls the ConfigMgr console.
DEFAULTSITESERVERNAME
: Specifies the site server FQDN to which the console will connect upon launch.
ENABLESQM
: Indicates the acceptance of joining the Customer Experience Improvement Program (CEIP)—0
for no or 1
for yes.
TARGETDIR
: Specifies a different folder if the default folder, %ProgramFiles%Microsoft Configuration ManagerAdminConsole, is not acceptable.
LangPackDir
: Specifies a folder where the language pack files are located if you wish to install a language pack.
The switches that do not begin with a slash (/
) all require the use of an equal sign (=
) between the switch and the value. Following are some examples of using the switches with consolesetup.exe:
consolesetup.exe /q DEFAULTSITESERVERNAME=armada.odyssey.com ENABLESQM=0
consolesetup.exe /q DEFAULTSITESERVERNAME=armada.odyssey.com ENABLESQM=1 LangPackDir=c:LangPacks
consolesetup.exe /uninstall
The Configuration Manager console is context sensitive, based on the security of each administrative user. As you begin to assign permissions to other users, you will notice that the console displays only what the user is allowed to manage.
The console is designed to reflect only what the administrative user is assigned to do. This behavior means specialized console customization is not necessary, as the console automatically displays what is pertinent. You therefore need to deploy only a single version of the console and can let the assigned security do the rest.
For an administrative user to use the ConfigMgr console, that user must be assigned to at least one role, or the console will fail to connect. Once a role is defined, when the console is opened, the objects that fall under the management of the administrative user are displayed and accessible. All other objects are hidden from view. The console displays content based on the assigned roles, scopes, and collections:
Roles: Visible workspaces, nodes, folders, objects, and actions are defined by the administrative user’s associated role.
Scopes: Only the objects associated with assigned scopes can be managed.
Collections: Only assigned collections can be viewed and managed.
Objects in the console exist in three states: shown, hidden, and disabled. Objects in a shown state do just as the name implies: If a user has permission to manage these objects, they display in the console. If the object is a folder or a node, the parent objects are also displayed.
By default, objects are hidden. Only when users are granted access to them do objects appear. Hidden behavior is determined by the following rules:
Actions: If an administrative user does not have permissions to perform the action, the action is not displayed.
Objects: If an object does not belong to a security scope assigned to the administrative user, the object is not displayed.
Nodes: Without access to manage items in the node, the node will not be displayed.
Workspaces: Without access to manage at least one node in the workspace, the workspace itself will not be displayed.
Objects that are disabled display as grayed-out objects in the console and do not allow full interaction. This is typical whenever a user is granted read access to an object.
During installation of the Configuration Manager console, a default site server is specified; the console will connect to this server upon opening. If no default is specified during installation, you are prompted to specify the default on first launch. You are free to connect to any site server to which you have access. By accessing the backstage, you can use the Connect to a New Site dialog to provide a site server name. You can launch multiple instances of the admin console to connect to different sites simultaneously.
There are few options for customizing the console, as an administrative user’s security context drives what is available for view and use. The ConfigMgr console allows for limited personalization to suit your taste, and it all has to do with the Navigation pane.
The default order of workspaces in the Navigation pane is Assets and Compliance, Software Library, Monitoring, and Administration. You can arrange this order to something that makes more sense for you. Perform the following steps to rearrange workspaces:
1. Click the arrow below the last workspace in the Navigation pane (see Figure 8.8).
2. When the menu opens, choose Navigation Pane Options.
3. In the Navigation Pane Options window (see Figure 8.9), click the workspace to move and then click either Move Up or Move Down as many times as needed to get the workspace where you want it.
4. When all the workspaces are arranged in your order of preference, click OK.
TIP: RESETTING WORKSPACES
If you need to reset the workspaces to their original order, follow the preceding steps to open the Navigation Pane Options dialog and select Reset. This places the workspaces back into their original order.
If the Workspaces pane overlaps the node list, you can collapse it. When it is collapsed, the workspaces are represented by only icons. Collapse the Workspaces pane by moving the separator bar down. Using the Show More Buttons and Show Fewer Buttons selections (see Figure 8.10) is the equivalent of using the separator bar.
A vertical separator bar also exists between the Navigation pane and the List and Detail panes. The List and Detail panes have a horizontal separator bar as well; it is used for resizing.
In-console alerts allow an administrator to configure basic monitoring for the health of the ConfigMgr environment, as well as note the success of deployments. Alerts are state-based (meaning they update automatically as the condition changes), providing a near real-time monitoring experience and subscription capability. However, ConfigMgr alerts are limited in functionality and should not be considered a monitoring solution as robust as is provided by other tools, such as System Center Operations Manager, which is designed to handle enterprise-level alerting, notification, and performance metric gathering. Microsoft Operations Management Suite (OMS) can also be used to capture data from the application log and forward events to your favorite IT service management tool.
Alerts are located in the Monitoring workspace of the Configuration Manager console. The Overview node provides a list of recent alerts. If you click the Alerts node, you can see the list of available alerts in the List pane, along with details of any highlighted alert in the Details pane.
Available actions are based on the state of the alert. ConfigMgr assigns the following five states for alerts:
Active: A specified condition is met.
Canceled: A specified condition is no longer met.
Disabled: The condition of an alert is not evaluated while in this state.
Never Triggered: An alert has been created, but no condition has yet been met.
Postponed: The same as disabled, with an expiration period to revert to an active state.
Figure 8.11 shows configured alerts that have not yet been triggered.
Alerts that bubble up in the ConfigMgr console support a variety of actions. As mentioned in the previous section, available actions are dependent on the state of the alert. For example, the Enable action is not available on an enabled alert. The available alert actions are as follows (see Figure 8.12):
Postpone: Postponing an alert essentially ignores the alert for a specified period of time. When the time period has lapsed, the alert is updated to its current state. You can only postpone active alerts.
Edit Comments: You can add or modify comments to provide additional context about an alert.
Configure: Configuring an alert provides the ability to change the name, severity, and definition.
Enable: You can enable the selected alert.
Disable: You can disable the selected alert.
Refresh: Refresh is not for a specified alert but rather refreshes the entire list of alerts.
Delete: Deleting an alert removes it from the Alerts node and the list of recent alerts.
CAUTION: USING THE DELETE ACTION
The three states—Postpone, Disable, and Delete—might be confusing at first since their descriptions are somewhat similar. Postpone and Disable are most alike; disabling an alert is much like postponing an alert without a time period. Delete, however, is very different from either Postpone or Disable. Deleting an alert modifies the alert configuration, turning off the alert. This is quite different from disabling an alert since the disabled alert configuration remains the same and can be reenabled. If you want to reestablish a deleted alert, you must create and configure it again.
Whereas you can view alerts in a single area of the ConfigMgr console (the Alerts node of the Monitoring workspace), alert configuration pages are scattered around the console. This creates a challenge because you need to know the locations of all the configuration areas for creating alerts. Table 8.1 shows the locations and functions of the alerts you can create.
Workspace |
Node |
Function |
Administration |
Sites |
Low free disk space alerts on the site database server. See Chapter 24, “Backup, Recovery, and Maintenance,” for additional information. |
Software Library |
Applications |
Alerts about deployment success or failure percentage meeting a specified threshold. More information is available in Chapter 14, “Distributing and Deploying Applications and Packages.” |
|
Software Updates Groups |
Alerts about deployment compliance failing to meet a specified threshold. More information is available in Chapter 15, “Managing Software Updates.” |
Monitoring |
Database Replication |
Alerts about a replication link not working for a specified duration. Additional information is available in Chapter 24. |
Assets and Compliance |
Device Collections |
Alerts about a value falling below a specified client check, remediation, or activity threshold. Chapter 9, “Client Management,” contains additional information for setting up alerts. Antimalware alerts for Endpoint Protection from client systems. You can find more detail in Chapter 19, “Endpoint Protection.” |
|
Compliance Settings |
Alerts about baseline deployment compliance falling below a specified threshold. Additional information is available in Chapter 10, “Managing Compliance.” |
The configuration of each is slightly different, but overall configuration uses the same basic concept: You need to enable an alert and specify a threshold value. Refer to the chapters listed in Table 8.1 for additional information.
Subscriptions specifically refer to malware alerts. An alert subscription sends an email whenever a malware condition is met.
This section provides an example of setting up a subscription for System Center Endpoint Protection. Perform the following steps:
1. Navigate to Monitoring -> Alerts -> Subscriptions.
2. On the ribbon bar, click Create Subscription.
3. In the New Subscription window, provide a name for the subscription.
4. Specify the email address of the alert recipient. If there are multiple recipients, separate the email addresses with semicolons (;).
5. Select the email language.
6. Select the appropriate alerts and click OK.
Figure 8.13 shows a fully configured alert subscription.
The Configuration Manager Service Manager console assists in managing the state of ConfigMgr components. The console, shown in Figure 8.14, can check component status, set logging, and control the running state.
While nearly all components should be in a running state, a handful of components run only when initiated. For example, the SMS_SITE_BACKUP service remains stopped until the backup operation for ConfigMgr is initiated.
Configuration Manager Service Manager can be launched either through the ConfigMgr console or directly by running the proper executable.
To launch Service Manager from the ConfigMgr console, follow these steps:
1. Navigate to Monitoring -> System Status -> Component.
2. On the ribbon bar, click Start and then select Configuration Manager Service Manager.
To start Configuration Manager Service Manager outside the ConfigMgr console, navigate to the %ProgramFiles%Microsoft Configuration ManagerAdminConsoleini386 folder and open the compmgr.exe file. To make this easier in the future, create a shortcut to the file, as the Start menu does not include a shortcut for this file.
Unlike when launching the Configuration Manager Service Manager console from the ConfigMgr console, you must provide a site server name to connect to when the Service Manager console initially opens. If you prefer to launch the console directed at a specific server, simply add the name of the site server after compmgr.exe. The following example shows how to open Configuration Manager Service Manager connecting to the Athena site server:
%ProgramFiles%Microsoft Configuration ManagerAdminConsoleini386 compmgr.exe Athena
You can perform several actions within the Configuration Manager Service Manager console. Configuration Manager components are managed in a similar fashion to standard Windows services: They can be started, stopped, paused, resumed, and queried.
Following are the options Configuration Manager Service Manager offers for managing components, listed in the order displayed on the toolbar shown in Figure 8.15:
Query: Use this action to detect the current status of a component.
Start: Use this action to start a component that is in a stopped state.
Pause: If you want to preserve a component’s runtime environment, pause the service. Data in the component log file will persist when paused. Keep in mind that certain components do not support pausing.
Resume: This action can be applied to any component in a paused state.
Stop: When there is no concern for the preservation of a component’s runtime environment or data in the component’s log file, use this action to shut down the component.
Logging: This action displays the log control dialog to control whether logging is enabled or disabled, the name and location of the log file, and the size of the log file.
NOTE: COMPONENT ACTIONS NOT AVAILABLE UNTIL AFTER QUERY
Unlike with Windows services, to perform an action against a component, you must first query. Actions are available based on the component’s status. For example, the resume action is available only when a component is paused.
The Configuration Manager Service Manager console supports the following general actions:
Clear status: This action simply blanks the component status.
Site refresh: This action refreshes the list of components.
Connect: This action displays the Connect to Site dialog. The Service Manager console supports connecting to multiple sites.
Disconnect: This action displays the Disconnect from Sites dialog. This dialog box supports selecting multiple sites and disconnecting from multiple sites at once.
TIP: PERFORMING ACTIONS AGAINST MULTIPLE COMPONENTS
While the Components node is selected, you can select multiple components by using Ctrl+click; or you can select all components by using Ctrl+A. When multiple components are selected, you can use the query action to check the status of the selected components.
In addition, the logging action displays a slightly modified log control dialog that allows the use of a same filename for all selected components.
PowerShell integration is a new addition to the admin console, starting with this version of Configuration Manager. You can launch a PowerShell command window or the PowerShell ISE from the top-left dropdown, as shown in Figure 8.16.
The first time you launch the window to connect to PowerShell, you are prompted about whether to run software from an untrusted publisher, as shown in Figure 8.17. Choose the appropriate answer for your organization, and a command prompt appears that includes the site code of the site to which you are connected.
When you launch the PowerShell ISE option, the ISE window loads a file with code to load the ConfigMgr module and connect to the site server. You can reuse this code in your automation scripts to eliminate the need to launch the ConfigMgr console. Figure 8.18 shows the .ps1 file.
Review the ConfigMgr cmdlet documentation at https://docs.microsoft.com/powershell/sccm/overview?view=sccm-ps.
By default, a local group called SMS Admins is granted the permissions required to access the SMS provider and the Common Information Model (CIM) repository. Whenever an administrative user is granted access to Configuration Manager, the user is added to the SMS Admins group and inherently receives these permissions.
NOTE: SMS ADMINS GROUP DOES NOT PROVIDE ADMINISTRATIVE ACCESS
Although the name SMS Admins might sound as if it grants full administrative rights to ConfigMgr, this is not the case. Even when you are a member of the SMS Admins group, you cannot access a database unless you have been granted administrative user database access as well. Think of it as an office building: The SMS Admins group is the key to the front, public space. Once inside, you must be given access to the individual office suites.
When you run the ConfigMgr console locally (on the same server where the SMS provider exists), it uses WMI to connect to the SMS provider, and in turn the SMS provider allows access to the site database. This is made slightly more complicated for remote connections with the added requirement for Distributed Component Object Model (DCOM) permissions.
Because Configuration Manager still uses WMI, and WMI relies on DCOM, it is vital that you understand the requirements for WMI. For information about remote WMI security requirements, see https://docs.microsoft.com/sccm/core/plan-design/hierarchy/plan-for-the-sms-provider.
Administrative users running the console from their workstations, where the SMS provider does not exist, require the Remote Activation DCOM privilege on any computer where the SMS provider is installed and providing access to the ConfigMgr database. (In most cases, the SMS provider is installed on the same server as the site server.)
By default, the local SMS Admins group has the following permissions applied:
Local Launch
Remote Launch
Local Activation
Remote Activation
It is important to note that for remote console access, only the Remote Activation privilege is required. Figure 8.19 shows a custom local group provided this privilege.
Along with DCOM permissions, WMI permissions are also required for ConfigMgr console access. By default, the SMS Admins group is given the permissions necessary to provide operability.
Permissions are applied to two different namespaces. The following privileges are granted to the SMS Admins group in the RootSMS
WMI namespace:
Enable Account
Remote Enable
Figure 8.20 shows the permissions assigned to the same custom group as in Figure 8.19 (SMS Admins), with the appropriate permissions granted to the RootSMS
namespace.
The SMS Admins group is provided a slightly different set of permissions than the RootSMSsite_<
site code>
WMI namespace:
Enable Account
Execute Methods
Provider Write
Remote Enable
Figure 8.21 shows the same custom group (SMS Admins) with the appropriate permissions for this namespace.
With the role-based ConfigMgr console, the expected behavior may not always be the outcome. Console problems often are due to insufficient or inappropriately assigned security privileges. The following sections describe how to troubleshoot issues with the ConfigMgr console.
Administrators cherish the rich, detailed logging provided in ConfigMgr. This detailed logging is available for the ConfigMgr console. Use the log to gain valuable insight and detail about console-related issues. The console logs to the SMSAdminUI.log file located in the following path:
<%ProgramFiles%>Microsoft Configuration ManagerAdminConsoleAdminUILog
If the default logging level in SMSAdminUI.log does not provide sufficient detail, you can increase the logging verbosity. To enable verbose logging, follow these steps:
1. Navigate to the following path:
<%ProgramFiles%>Microsoft Configuration ManagerAdminConsolein
2. Open the file Microsoft.ConfigurationManagement.exe.config.
3. Search for the line <source name="SmsAdminUISnapIn" switch-Value="Error" >
and change Error
to Verbose
.
4. If the ConfigMgr console is open, restart the console to cause the setting to take effect.
CAUTION: DO NOT LEAVE LOGGING SET TO VERBOSE
When logging levels are increased, the log size and activity to write logs also increase. If you enable verbose logging, be sure to change the logging level back to its default when you are finished.
At a minimum, the required DCOM permission is Remote Activation. To verify the Remote Activation permission, perform the following steps:
1. On the site server (and any SMS provider computer), start the Component Services console by clicking Start -> Run and then typing dcomcnfg.exe.
2. Expand Component Services -> Computers.
3. Right-click My Computer and select Properties from the menu.
4. Switch to the COM Security tab.
5. In the lower section, titled Launch and Activation Permissions, click Edit Limits. At this point, if permissions are correct (refer to Figure 8.19 in the “Security Considerations for the Console” section), the remaining steps are not necessary. If permissions are missing, proceed to step 6.
6. Click Add and specify the interested account or group. Click OK.
7. In the permissions area, deselect all other values and select Remote Activation.
8. Click OK to close the Launch and Activation Permission dialog box and click OK to close the My Computer Properties dialog box.
9. In the permissions area, deselect all other values and select Remote Activation.
10. Close the Component Services console.
Validating WMI permissions occurs at two different WMI namespaces. Even though the namespaces are along the same path, the privileges differ for the two namespaces, and therefore the child namespaces do not inherit from the parent. Note that the screenshots shown earlier in this chapter illustrate providing access to a custom local group (SMS Admins).
To verify WMI permissions, perform the following steps:
1. On the site server (and any SMS provider computer), start the Component Services console by selecting Start -> Administrative Tools -> Computer Management.
2. Expand the Services and Applications node and right-click WMI Control.
3. Select Properties in the menu to launch the WMI Control Properties dialog.
4. Switch to the Security tab and expand the Root node. Select SMS and click Security.
5. Verify that the following permissions are listed:
Enable Account
Remote Enable
6. Expand the SMS node and select the site_<site code> node below it.
7. Click Security.
8. Select Properties in the menu and verify that the following permissions are listed:
Enable Account
Execute Methods
Provider Write
Remote Enable
9. Close all dialog boxes as necessary.
Refer to Figures 8.20 and 8.21, earlier in this chapter, for an illustration of the permissions applied properly.
Console connection status messages are often vague, providing very little help for determining issues. Even the SMSAdminUI.log might not provide much value. Situations like these may leave you wondering in which layer the permissions issue is occurring.
It is helpful to filter out whether a problem is occurring both locally and remotely. Knowing this information helps isolate where to look for problems. To test this scenario, launch the console from the administrative user’s desktop and record the results. When you are done with that, launch the console under the administrative user’s context on the ConfigMgr server. Table 8.2 lists the components to examine.
If Local Console Fails |
And Remote Console Fails |
Check These Components |
× |
× |
WMI, ConfigMgr |
|
× |
WMI, DCOM |
Table 8.3 describes issues you might experience while using the ConfigMgr console.
Error |
Description |
Error: Configuration Manager cannot connect to the site. |
If the SMSAdminUI.log contains “Insufficient privilege to connect, error: Access is denied.” and an administrative user does not have local administrator privileges to the ConfigMgr site server, he or she is most likely missing DCOM privileges. Ensure that the user is a member of the Distributed COM Users local group. If the SMSAdminUI.log contains “Transport error; failed to connect, message: ‘The SMS Provider reported an error’” Ensure that the user is a member of the SMS Admins local group. If the user is a member of the SMS Admins local group, ensure that an administrative user context has been created for that user with at least one role assigned. |
Expected objects are not displayed in the console. |
Ensure that the administrative user has the correct security scopes and collections assigned. |
Expected workspaces, nodes, or actions are not displayed in the console. |
Ensure that the administrative user is assigned the correct security role that grants access to the correct objects. |
This chapter introduced the System Center Configuration Manager console and covered the console’s panes and other features. It stepped through a console installation and discussed automating the console installation. This chapter described how to use the secondary console, Configuration Manager Service Manager, and actions to control the various ConfigMgr components.
The chapter ended with a troubleshooting section to help diagnose common console problems. Chapter 9 discusses managing clients.