none
Permission problems after OS upgrade on SCCM site server RRS feed

  • Question

  • We have a single site server, SCCM 2012 R2 SP1, in a single domain that I upgraded the OS from Server 2012 to Server 2012 R2. This is supported according to the SCCM docs. After sorting out some problems with WSUS, the site server appears to be working.

    The site server won't allow remote non-administrator users to connect using the SCCM Console now, however. Our IT department uses local non-admin user accounts for day-to-day work, even for basic administration of Active Directory, but the IT department AD group does have the SCCM "Full Administrator" role. A domain admin can otherwise use the Console from a remote computer, so network connectivity and firewall issues are sorted.

    This worked prior to the OS upgrade. Had something changed as part of that upgrade? I already took a look at DCOM permissions; those appear to be unchanged and have the local group "SMS Admins" specified.

    The site server's local group "SMS Admins" has the domain global group "SMS Administrators" and "IT Department" listed as members; this hasn't changed.

    Other permissions seem OK; the Remote Tools Operator role seems to work as intended for non-admins.

    Monday, August 15, 2016 12:27 PM

Answers

  • So, duh... The last line in the error message from the Remote Console told me what I needed: The WMI permissions were overwritten during the OS upgrade, and after I restored the site server's SMS Admins local group to them, Remote Console non-admins could use the Remote Console again.

    To fix this, on the site server launch wmimgmt.msc console, then bring up the local computer's properties and Security tab. Then browse to root / SMS and root / SMS / site_[site name]. Add the SMS Admins local group back to both of these, and make sure they have Execute Methods, Provider Write, Enable Account, and Remote Enable allowed.

    • Marked as answer by Gordon Fecyk Tuesday, August 16, 2016 3:09 PM
    Tuesday, August 16, 2016 3:09 PM

All replies

  • What errors do those remote users get? What's in the admin console log then? And smsprov.log on the site server.

    Torsten Meringer | http://www.mssccmfaq.de

    Monday, August 15, 2016 12:50 PM
  • The error message is pretty generic:

    The Configuration Manager console cannot connect to the Configuration Manager site database. Verify the following:

          • This computer has network connectivity to the SMS Provider computer.
          • Your user account has Remote Activation permission on the Configuration Manager site server and the SMS Provider computer.
          • The Configuration Manager console version is supported by the site server.
          • You are assigned to at least one role-based administration security role.
          • You have the following WMI permissions to the Root\SMS and Root\SMS\site_<site code> namespaces: Execute Methods, Provider Write, Enable Account, and Remote Enable.

    As other users that have Domain Admin access can use a remote console, I think I can rule out network connectivity and console version.

    The smsprov.log doesn't tell me much. The time stamp doesn't change when I attempt a remote console session as a non-admin. It will log a successful console logon from a remote user that has admin permissions.

    The smsadminui.log file is stored in a folder that non-admins don't have read/write access to, so this doesn't normally have anything when a local non-admin uses the console. I can grant read/write access to the log file to local non-admins though, and doing so gives me a generic Access Denied exception. I have reviewed the DCOM permissions though; what else should I check? Has Remote Activation or WMI permissions changed with the OS upgrade?

    [7, PID:5448][08/15/2016 10:16:09] :System.Management.ManagementException\r\nAccess denied \r\n   at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
       at System.Management.ManagementScope.InitializeGuts(Object o)
       at System.Management.ManagementScope.Initialize()
       at System.Management.ManagementObjectSearcher.Initialize()
       at System.Management.ManagementObjectSearcher.Get()
       at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.Connect(String configMgrServerPath)\r\nManagementException details:
    [7, PID:5448][08/15/2016 10:16:09] :Transport error; failed to connect, message: 'The SMS Provider reported an error.'\r\nMicrosoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryException\r\nThe SMS Provider reported an error.\r\n   at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.Connect(String configMgrServerPath)
       at Microsoft.ConfigurationManagement.AdminConsole.SmsSiteConnectionNode.GetConnectionManagerInstance(String connectionManagerInstance)\r\nAccess denied
    \r\nSystem.Management.ManagementException\r\nAccess denied \r\n   at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
       at System.Management.ManagementScope.InitializeGuts(Object o)
       at System.Management.ManagementScope.Initialize()
       at System.Management.ManagementObjectSearcher.Initialize()
       at System.Management.ManagementObjectSearcher.Get()
       at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.Connect(String configMgrServerPath)\r\nManagementException details:
    [7, PID:5448][08/15/2016 10:16:14] :System.Management.ManagementException\r\nAccess denied \r\n   at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
       at System.Management.ManagementScope.InitializeGuts(Object o)
       at System.Management.ManagementScope.Initialize()
       at System.Management.ManagementObject.Initialize(Boolean getObject)
       at System.Management.ManagementObject.InvokeMethod(String methodName, ManagementBaseObject inParameters, InvokeMethodOptions options)
       at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters, Boolean traceParameters)\r\nManagementException details:

    Monday, August 15, 2016 3:20 PM
  • So, duh... The last line in the error message from the Remote Console told me what I needed: The WMI permissions were overwritten during the OS upgrade, and after I restored the site server's SMS Admins local group to them, Remote Console non-admins could use the Remote Console again.

    To fix this, on the site server launch wmimgmt.msc console, then bring up the local computer's properties and Security tab. Then browse to root / SMS and root / SMS / site_[site name]. Add the SMS Admins local group back to both of these, and make sure they have Execute Methods, Provider Write, Enable Account, and Remote Enable allowed.

    • Marked as answer by Gordon Fecyk Tuesday, August 16, 2016 3:09 PM
    Tuesday, August 16, 2016 3:09 PM
  • This article discusses the issue but only under the section for upgrading the site server to Windows Server 2016.  https://docs.microsoft.com/en-us/sccm/core/servers/manage/upgrade-on-premises-infrastructure#upgrade-windows-server-2008-r2-to-windows-server-2012-r2

    I had the issue when upgrading from 2008 R2 to 2012 R2.  I was on build 1610 when I upgraded the OS.

    Monday, February 6, 2017 5:18 PM
  • I have performed an in place upgrade from 2012 R2 to 2016 and under root there is no SMS folder. Should I perhaps perform a site reset or is there something else going on?

    Wednesday, September 20, 2017 5:12 PM
  • I see Local in the screenshot are you logged on directly to the site server and checking WMI security?
    Wednesday, September 20, 2017 5:16 PM
  • I am. This is on the server just upgraded.
    Wednesday, September 20, 2017 5:18 PM
  • I have not upgraded from 2012R2 to 2016.  I didn't see any caveats other than removing SCEP before the OS upgrade and performing a few post upgrade steps.  Did you complete those?  If you did complete everything, then I suggest you open a case with Microsoft.
    Wednesday, September 20, 2017 5:25 PM
  • I have not upgraded from 2012R2 to 2016.  I didn't see any caveats other than removing SCEP before the OS upgrade and performing a few post upgrade steps.  Did you complete those?  If you did complete everything, then I suggest you open a case with Microsoft.

    Yeah, I followed it to a T.

    The infrastructure seems fine, I just cannot connect to the site using the console on the server itself.

    Wednesday, September 20, 2017 5:26 PM
  • Can you query the SMS namespace using wbemtest?
    Wednesday, September 20, 2017 5:27 PM
  • When I try to connect to \\<siteserver>\root\sms I get Invalid Namespace as a response.

    I have a suspicion that what is happening is when the OS upgrade was performed, I disabled the SMS_Executive service so in theory I could go back to a clean snapshot of the server if needed. I know snapshots are explicitly not supported but did it anyway. This is a test host, so I will try a site reset and see if it helps.


    • Edited by BryanCP Wednesday, September 20, 2017 5:37 PM
    Wednesday, September 20, 2017 5:36 PM
  • Did you disable the SMS_Executive service before or after the OS upgrade?
    Wednesday, September 20, 2017 5:45 PM
  • Before the OS upgrade.
    Wednesday, September 20, 2017 5:46 PM
  • That is not part of the upgrade procedure and could be the cause of your issue.  I took snapshots of our entire ConfigMgr environment while they were powered off prior to the upgrade in case I needed to roll back.  This included all core site systems including the standalone database/reporting server but not systems in remote sites that were only distribution points.  You could try reverting your snapshots and perform the OS upgrade again without disabling the SMS_Executive service
    Wednesday, September 20, 2017 5:49 PM
  • The site reset did not fix the issue, so I am going to revert it to before thr upgrade, enable SMS_SEXECUTIVE, and then try it again. Unfortunately there was some communication between this site and the CAS in our environment after the upgrade so hopefully it won't cause any issues.

    Thanks for the guidance, I will report back after my work is done.

    Wednesday, September 20, 2017 6:01 PM
  • I reverted to my snapshot and performed the OS upgrade with SMS_EXECUTIVE enabled and the SMS entry is still not showing up in WMI.

    I reverted again to ensure the Root\SMS WMI entry was there prior to the upgrade and it is, so the OS upgrade is definitely the cause. I'm at a loss here.

    • Edited by BryanCP Thursday, September 21, 2017 4:43 PM
    Thursday, September 21, 2017 3:54 PM
  • BryanCP - I encountered the same thing as you. I had not disabled SMS_exec prior to upgrade but I did stop it. I had the same problems you outlined after the upgrade as well. Ultimate, I uninstalled the primary site, and then did a site restore from backup and everything has appeared to come back up as normal and my SMS WMI namespace is visible to me again.
    Tuesday, November 7, 2017 2:47 AM
  • I goofed up and forgot to reply to this thread. The issue was resolved on my end, but I am not 100% sure what did it. As I mentioned earlier I performed a site reset and that did not fix it. Later I installed all pending Windows Updates on the site server and after the restart the SMS WMI namespace was there again.

    When I upgraded my production server to Server 2016 I did both steps (site reset and applying all pending updates) and SMS was there. So a combination of those 2 things as well as a little patience seemed to do the trick.

    Wednesday, November 8, 2017 12:51 PM
  • Although this is an old thread, I want to confirm that doing a site reset resolved the case for me.
    Tuesday, June 12, 2018 7:33 AM