Home networking sms troubleshooting windows server

Fix SMS Admin Console Connectivity Issues on Windows Server: A Troubleshooting Guide

Updated: • 0 • min read
Table of Contents

This guide provides a comprehensive approach to troubleshoot new or existing SMS Administrator Consoles that fail to connect to the site server. Connectivity issues can manifest as a “Connection Failed” message, or the console nodes may not display content after a successful connection. Understanding the underlying causes and systematically troubleshooting them is key to restoring functionality.

Commonly, the AdminUI.log file on the server will log various error codes indicating a problem. These error codes provide clues about the nature of the connectivity failure. For instance, errors such as -2147023174 [0x800706ba] or -2147024891 [0x80070005] often point to issues with RPC (Remote Procedure Call) availability or access permissions.

Error Code Description Common Cause
-2147023174 [0x800706ba] RPC server is unavailable. Network connectivity, firewall blocking, DNS issues, DCOM misconfiguration, or the SMS Provider service is not running.
-2146959355 [0x80080005] Server execution failed. Insufficient permissions (WMI, DCOM), or an issue with the underlying WMI service or SMS Provider.
-2147217394 Generic connection error. Broad range of issues, often related to WMI or DCOM.
-2147217389 [0x80041013] Failed to execute method GetProviderVersion! WMI Provider access problems, incorrect site code in WMI, or insufficient WMI permissions for the SMS_site code namespace.
-2147024891 [0x80070005] Access is denied. User account lacks necessary WMI or DCOM permissions, or a firewall is blocking access.

Troubleshooting SMS Admin Console Connectivity on Windows Server

Granting Access to the SMS Administrator Console

For any user to access a local or remote SMS Administrator Console, they must be a member of the local SMS Admins group. This group is specifically granted Enable Account and Remote Enable permissions on the Root\SMS WMI namespace. These permissions are crucial because the SMS Admins group provides its members with the necessary access to the SMS Provider through WMI.

It is recommended to add users to the SMS Admins group when they require console access but do not necessarily need to be Local Administrators on the server. If you prefer to use a different local group for console access, ensure that this alternative group is granted the same WMI permissions as the SMS Admins group. Proper permission configuration is a foundational step in resolving connectivity issues.

To effectively grant access to the SMS Administrator Console, follow these systematic steps:

  1. Create a Global Group: Begin by creating a global group within your domain. This group should contain all users who require specific access to the SMS Administrator Console, centralizing user management.
  2. Add to SMS Admins Group: Add this newly created global group, or individual domain user accounts if preferred, to the local SMS Admins group on the SMS site server. This establishes the initial membership required for console access.

  3. Configure SMS Permissions: Configure the specific SMS permissions for the global group you created. This step defines what functionality members of the group can perform within the console.

    • Note: You must have administrator privileges and full permissions on the site to complete this step.
    • If you can connect to the database but nodes do not enumerate, thoroughly examine the SMS permissions granted to the global group or specific user under the Security node in the SMS Administrator Console. Verify that nodes such as collections, packages, or other crucial content are properly displayed.

  4. Utilize the Security Wizard: To grant these permissions, right-click the Security Rights node in the SMS Administrator Console, select All Tasks, and then click Manage SMS Users. This action initiates the Security Wizard, which guides you through adding, removing, or modifying security settings for users and groups efficiently.

General Troubleshooting for Console Connectivity

When experiencing SMS Administrator Console connectivity issues, especially with remote consoles, several key areas warrant investigation. Ensuring that the latest service packs are applied and that fundamental security configurations are correct can often resolve common problems. A systematic approach to these general checks can save significant troubleshooting time.

One critical aspect is verifying the SMS service pack installation on the remote console. If the latest SMS service pack has not been applied, you might encounter errors like CLASS_SMS_ContextMethods, METHOD_GetContextHandle! Failed to set the connection. error code: -2147217407 in the AdminUI.log. Running the Setup program from the service pack source can help determine if the SMS Administrator Console is the sole component needing an upgrade.

Consider the following specific issues to troubleshoot SMS Administrator Console connectivity:

  • Windows Server 2003 with Service Pack 1 (SP1): If the SMS site server is running Windows Server 2003 with SP1, a new local group named Distributed COM Users is created. To resolve connectivity issues, ensure that users attempting to make remote connections to the SMS Administrator Console are added to this local group.
  • SMS Admins Group Membership: Verify that the user attempting to connect is either a direct member of the SMS Admins group or a member of a global group that is nested within the SMS Admins group. The SMS Admins group is created during SMS site installation and holds necessary permissions to the SMS and SMS_site code namespaces in the Windows Management Instrumentation (WMI) repository.
  • Previous SMS Installations: If the server previously hosted an SMS installation, there might be multiple site codes present in the SMS_ProviderLocation class within the site server’s SMS namespace. Using the WBEMtest tool, identify and delete any site codes that are no longer valid or associated with an active site on the server.
  • DCOM Configuration Utility (Dcomcnfg.exe): On the site server, confirm the property settings defined in the Dcomcnfg.exe utility. Access the Default Properties tab and ensure that the Enable Distributed COM on this computer checkbox is selected. Additionally, verify that the Default Authentication level is set to Connect and the Default Impersonation level is set to Identify. Incorrect DCOM settings can significantly impact remote connectivity.

Deep Dive into WMI and Server Connectivity

Once general checks are complete, deeper investigation into WMI namespace connectivity and the SMS Provider server is crucial. These components are fundamental to how the SMS Administrator Console retrieves information and performs operations. Issues here often manifest as access denied errors or incomplete node enumerations within the console.

Troubleshooting SMS Namespace Connectivity

To verify the user’s ability to connect to the SMS namespace and the SMS_‘sitecode’ namespaces, use the WBEMtest tool. This utility provides a direct way to test WMI connections and enumerate classes.

Follow these steps for a thorough check:

  1. Click Start, then Run, type wbemtest, and press Enter. This will open the Windows Management Instrumentation Tester.
  2. Click the Connect button. In the Namespace field, type \\siteserver\root\sms (replacing siteserver with your actual site server name), and then click Login. This attempts to establish a connection to the primary SMS namespace.
  3. Click Enum Classes, then select Recursive, and click OK. In the Query Result list, double-click SMS_ProviderLocation.
  4. Click Instances within the SMS_ProviderLocation window, then double-click the line containing your target site code (e.g., SMS_ProviderLocation.SiteCode="XXX").
  5. In the Properties section, locate the NamespacePath line. You may need to double-click this line to view the complete path. Copy this NamespacePath value to your clipboard (e.g., \\server_name\root\sms\site_XXX).

Successfully completing this procedure indicates that you can connect to the site server and enumerate the SMS namespace, which is a positive sign for underlying WMI health.

Troubleshooting Server Connectivity (Provider)

Next, determine if you can connect to the server hosting the SMS Provider, which is typically the same server identified by the NamespacePath value. This step verifies direct access to the component responsible for serving SMS data.

  1. Close all open WBEMtest windows to ensure a clean start for the next connection attempt.
  2. Click Connect in a new WBEMtest window. Paste the NamespacePath you copied in the previous section (from step 5 of “Troubleshooting SMS Namespace Connectivity”) into the Namespace field, and then click Login.
  3. Click Enum Classes, select Recursive, and then click OK.
  4. In the Query Result list, double-click SMS_Site.

If you receive an “access denied” error message during this procedure, it often points to a permissions issue. Two common causes are:

  1. Security Configuration Wizard Impact: If the Security Configuration Wizard was run on the server hosting the SMS Provider, it might have inadvertently restricted WMI access. The wizard, by default, may not recognize the SMS Provider and might disable necessary services. You must enable the Remote WMI service within the wizard to allow the SMS Administrator Console (local or remote) to connect to the SMS namespace in WMI.
    • To enable Remote WMI, select this option on the Select Administration and Other Options page of the Security Configuration Wizard.
  2. Account Permissions for Provider Namespace: The account used for connection may lack sufficient permissions to the provider’s namespace. To verify and modify these permissions:
    • On the server where you enumerated the SMS site, open wmimgmt.msc (WMI Control).
    • Right-click WMI Control, then click Properties. Go to the Security tab, expand Root, and click SMS.
    • Click Security in the results pane to view the permissions. Click Advanced, then select SMS Admins, and click View-edit.
    • For the SMS namespace, the SMS Admins group must have Enable account and Remote enable permissions.
    • Repeat these steps for the SMS_xxx namespace (where xxx is your site code) and grant Remote Enable permission to the user or group. Lacking these specific WMI permissions can cause “access denied” errors in the AdminUI.log.

Addressing Other Security Considerations

Beyond WMI and DCOM basic configurations, certain security settings, especially those introduced with Windows XP SP2 and Windows Server 2003 SP1, can block SMS console connectivity. These layers of security require specific configurations to allow the necessary communication channels.

Verifying Windows Firewall Configuration

Windows XP SP2 and Windows Server 2003 SP1 include the Windows Firewall feature, which can block DCOM and WMI traffic. If the SMS Administrator Console is run on a computer with the firewall enabled, you must explicitly allow the Unsecapp.exe program and TCP port 135 to pass through the firewall.

Follow these steps to configure Windows Firewall:

  1. Click Start, then Run, type firewall.cpl, and click OK.
  2. On the General tab, ensure On is selected to enable the firewall, and clear the Don’t allow exceptions checkbox.
  3. Navigate to the Exceptions tab and click Add Program.
  4. Click Browse, type %windir%\System32\Wbem\Unsecapp.exe in the File name box, and click Open. Adjust the scope if necessary by clicking Change scope, then OK. Click OK to close the Add a Program dialog box.
  5. In the Programs and Services list, ensure the Unsecapp.exe checkbox is selected.
  6. Click Add Port. In the Port number box, type 135. Select TCP, and provide a descriptive name for the exception (e.g., “SMS Admin Console RPC”). Define the scope if needed, then click OK twice to close the Add Port dialog box.
  7. In the Programs and Services list, verify that the checkbox for the newly added exception (for port 135) is selected.
  8. Finally, click OK to apply the firewall changes.

Checking DCOM Security Settings

Warning: Only make these changes if adding Unsecapp.exe and TCP port 135 to the Windows Firewall exceptions list does not resolve the issue. Modifying DCOM security settings incorrectly can introduce security vulnerabilities.

If firewall exceptions are insufficient, you might need to adjust anonymous remote permissions in DCOM for the client computer. On the Windows XP SP2-based computer running the SMS Administrator Console:

  1. Click Start, then Run, type dcomcnfg.exe, and click OK.
  2. In the Component Services window, navigate to Console Root > Component Services > Computers > My Computer.
  3. Right-click My Computer and select Properties.
  4. In the My Computer Properties dialog box, click the COM Security tab.
  5. Under Access Permissions, click Edit Limits.
  6. Locate and click ANONYMOUS LOGON.
  7. Under Permissions for ANONYMOUS LOGON, ensure Allow setting for Remote Access is checked.
  8. Click OK twice to close the dialog boxes.
  9. Restart your computer for the changes to take effect.

Determine Whether Default DCOM Permissions Have Been Changed

Check for the DefaultAccessPermission value under the registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole. If this value exists, it indicates that the default DCOM permissions have been modified. If it does not exist, the default DCOM permissions are in effect.

As a last resort, if other troubleshooting steps fail, deleting the DefaultAccessPermission value will reset all default DCOM permissions. This is a drastic measure and does not guarantee a solution.

To delete the DefaultAccessPermission value:

  1. Click Start, then Run, type regedit, and click OK.
  2. Navigate to and click the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole.
  3. In the right pane, right-click DefaultAccessPermission, and then click Delete.
  4. Confirm the deletion by clicking Yes in the Confirm Value Delete dialog box.
  5. Exit Registry Editor.
  6. Log off from your computer, and then log back on for the changes to apply.

Modifying Anonymous Logon Behavior

If previous procedures do not resolve permissions issues, especially when the console is partially available or users are still denied access, it might be difficult to identify every resource requiring anonymous access on the Windows XP computer. In such scenarios, you might need to force the Windows XP computer to include the Anonymous Logon security group in the Everyone security group.

Windows XP includes the EveryoneIncludesAnonymous registry entry to support this functionality. When this entry is set to REG_DWORD 0x1, the Local Security Authority (LSA) includes the Security Identifier (SID) of the Everyone security group in the anonymous user’s access token.

To set the value of the EveryoneIncludesAnonymous registry entry, use either of the following methods:

Method 1: Set the EveryoneIncludesAnonymous Registry Entry by Using Local Security Settings

  1. Click Start, then Run, type Control admintools, and click OK.
  2. Double-click either Local Security Policy or Domain Security Policy (if applicable on domain controllers).
  3. Double-click Local Policies, and then click Security Options.
  4. Right-click Network access: Let Everyone permissions apply to anonymous users, and then click Properties.
  5. To enable anonymous users to be members of the Everyone security group, click Enabled. To prevent the inclusion of the Everyone security group SID in the anonymous user’s access token (which is the default setting in Windows XP), click Disabled.

Method 2: Set the EveryoneIncludesAnonymous Registry Value by Using Registry Editor

  1. Click Start, then Run, type regedit, and click OK.
  2. Navigate to and click the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
  3. Right-click EveryoneIncludesAnonymous, and then click Modify.
  4. To enable anonymous users to be members of the Everyone security group, type 1 in the Value data box. To prevent the inclusion of the Everyone security group SID in the anonymous user’s access token, type 0 in the Value data box. By default, EveryoneIncludesAnonymous is set to 0 in Windows XP.
  5. Exit Registry Editor.
  6. Restart the computer for the changes to take effect.

Advanced Connectivity Tests and Network Issues

Beyond WMI and DCOM configurations, network-level issues can significantly impact SMS Administrator Console connectivity. These often involve RPC communication and proper name resolution, which are critical for distributed applications like SMS.

Additional Connectivity Tests

Start the WMI Control on the site server (not necessarily the provider server if they are separate). Click the Logging tab and set the logging level to Verbose to increase the detail in the Windows_folder\System32\Wbem\Logs\Wbemcore.log file. Analyze this log on the site server to observe all generated WMI traffic. Look specifically for the query for SMS_Providerlocation that occurs when an SMS Administrator Console attempts to connect. Its presence confirms communication between the console and the site server.

Connectivity issues can also stem from the site server’s ability to communicate back to the requesting SMS Administrator Console. This bidirectional communication is crucial. Problems may arise if:

  • RPC Server is Unavailable: The Remote Procedure Call (RPC) server on either end is not running or is blocked.
  • DNS Name Resolution Issue: Incorrect or stale DNS records can lead to connection failures. The “Connection Failed” error might occur if name resolution isn’t completed correctly.

To determine if you are experiencing a name resolution issue, use the WBEMtest tool and attempt to connect to the site server using its IP address (e.g., \\111.222.333.444\root\default). If you can connect using the IP address but not using the NetBIOS name of the site server, you likely have a name resolution problem. Verify your WINS or DNS configurations to resolve this.

When nodes are expanded in a remote SMS Administrator Console, the SMS site server initiates a DCOM connection to the computer where the console is installed. If an invalid DNS record exists for the console computer, the SMS site server might attempt to connect to the wrong IP address, leading to node expansion failures and “WMI connection has been dropped” errors in the AdminUI.log. To troubleshoot this:

  1. Run the nslookup <console_computer_name> command to ensure the name resolves to the correct IP address.
  2. If an invalid DNS registration exists, remove it and identify the cause to prevent recurrence (e.g., a VPN address that was not properly deregistered).
  3. After resolving the DNS issue, run ipconfig /flushdns at a command prompt on the SMS 2003 site server to clear its DNS cache.
  4. If the fully qualified domain name of the Windows XP SP2-based computer cannot be resolved via DNS, consider creating an entry in the hosts file on the SMS 2003 site server to map the console computer’s FQDN to its IP address.

Known Issues with Microsoft ISA Server or Checkpoint VPN Software

Remote console users connecting from Windows 2003 SP1 computers might experience issues expanding certain nodes if they are using specific firewall or VPN products, such as Checkpoint Software Technologies products or Microsoft Internet Security and Acceleration (ISA) Server. These products can deny network requests, particularly Remote Procedure Call-based operations.

This issue typically occurs when the RPC connection from the client is established over TCP port 135 and is enabled, but the response from the Central Site server is over ephemeral ports (ports above 1024) which the firewall then blocks. To mitigate this, configure both the client and the server to restrict the range of ports used by RPC connections, and then open this specific range on your firewall. This ensures that RPC communication occurs only over a predefined and unblocked set of ports, allowing the console to function correctly through the firewall.

We hope this comprehensive troubleshooting guide helps you resolve SMS Administrator Console connectivity issues on your Windows Server environment. Understanding the interplay of WMI, DCOM, network configurations, and security permissions is crucial for maintaining a healthy SMS infrastructure.

Did these steps help you resolve your connectivity problems? Share your experiences, challenges, or any additional tips you might have in the comments section below!

Post a Comment