locked
Limited permissions on CAS after expanding Primary site RRS feed

  • Question

  • **Note, I was going to add screenshots, but apparently my account is not verified, so I will just describe**

    I recently had a need to expand our stand alone primary site into a CAS.  While there were a few bumps on the road in replication issues, I have managed to get those sorted out, but now I have a permissions issue.  Originally I thought this was related to the replication problem, but after getting the green light on replication, I realize that is not the case.


    From the Primary site, I am unable to even view the CAS under Sites or Servers and Site System Roles (not sure if this is by design)


    Even more strange is from the CAS, I have what appears to be limited user rights.  I am unable to add/remove roles to anything, and I cannot change user permissions either.  The Primary I expanded from I am a Full Administrator, and my account was used to expand the Primary into a CAS.


    Any ideas as to how to resolve this?  I even tried adding the roles via powershell, but no such luck.  It isn't a big deal for the Primary, or any of my DP's because I can manage all of those fine via the Primary.  However I have roles I need to add to the CAS (AI, SUP, SCEP), but I am unable to do so.  As well as menu's all over the CAS console are greyed out in random areas, which is what leads me to believe my permissions are somehow different in that console than when I'm connected to my Primary.

    Thank You

    Friday, September 23, 2016 1:46 PM

Answers

  • So the issue was related to the expansion of the CAS.  Originally I had a replication issue which I fixed, but apparently the replication issue marked the CAS as "Expansion Failed" and it would not retry doing the expansion without some SQL query magic.  If you run into an issue like this, it is recommended you use Microsoft CSS to help resolve.  

    To set the site status back to where it will retry site expansion, we ran the following:

    select * from serverdata

    update ServerData set SiteStatus=125 where SiteStatus=450

    select * from sites

    update Sites set DetailedStatus=125 where SiteCode='CAS'

    Obviously the last line 'CAS' will be the sitecode of your CAS.  You can find the SiteStatus that a site is currently in by looking in the console and making sure to have the column active that shows "Requested Status".  Before the fix, my CAS was in 450.  After running the commands, you could see in the SMSProv.log the progress.

    • Marked as answer by J.Phiffer Monday, October 31, 2016 1:19 PM
    Monday, October 31, 2016 1:19 PM

All replies

  • What do you mean you can't change user permissions? What error do you get? Where are you trying to change permissions?

    What Security roles do you have assigned to your account?


    Garth Jones

    Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

    Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

    Friday, September 23, 2016 2:54 PM
  • Thank you for the reply Garth.  Huge fan of all your reporting related post :)

    So when my console is connected to the CAS, my account is listed as a Full Administrator, but if I go to the properties page, the Add/Remove buttons are greyed out.

    Servers and Site System Roles if I right click on any of the servers, the option to add a role just doesn't even show up.  I also couldn't remove an existing role if I wanted to.

    Those are really just two examples, but really I can go into the properties of pretty much anything and I receive greyed out options that I cannot change.  These are all options that if I connect the console to my primary server, I can modify without issue.  I'll see if I can get that account verified as well so I can post pictures/links in the future.

    Thanks!

    Friday, September 23, 2016 3:29 PM

  • From the Primary site, I am unable to even view the CAS under Sites or Servers and Site System Roles (not sure if this is by design)

    Dear Sir,

    This should be by designed and this is why it's always recommended that CM administrators use CAS to manage.

    Can you review your account permission (Role based administratiron permission) when you're connecting to your CAS? Go and check Monitoring workspace to be sure components are working fine.

    Best regards

    Frank


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, September 26, 2016 3:18 AM
  • All components are green checked.  Also my account is listed as a Full Administrator with the scope being All.  Not sure if there are some how different rights between the CAS console and Primary, but I would assume it should have inherited the rights from the Primary I expanded from.

    Now that I can post screenshots, one of many examples of options to manage that are missing, I am unable to add/remove roles from my CAS.  Which is really my primary objective at the moment as I need to get my SUP and AI back in place.

    Also my permissions as viewed from the CAS




    • Edited by J.Phiffer Monday, September 26, 2016 12:42 PM
    Monday, September 26, 2016 12:39 PM
  • What security scope do you have?

    FYI I'm at Ignite so I'm check thing off and on...


    Garth Jones

    Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

    Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

    Tuesday, September 27, 2016 2:51 PM
  • Relevant entry from SMSProv log when I try to add a role via powershell

    SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    CExtUserContext::EnterThread : User=Domain\jphiffer Sid=0x0105000000000005150000000B75D97693E3624807E53B2B90780000 Caching IWbemContextPtr=0000003CA9F4E080 in Process 0x136c (4972) SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    Context: MachineName=CfgMgrCAS.Domain.com SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    Context: ApplicationName=AdminUI.PS.Provider.dll SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    Context: ObjectLockContext=826b4685-4913-4856-a258-c529ca8b899c SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    Context: __ClientPreferredLanguages=en-US,en SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    Context: __CorrelationId={B9243876-1502-0002-B343-24B90215D201} SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    Context: __GroupOperationId=53582 SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    CExtUserContext : Set ThreadLocaleID OK to: 1033 SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    CSspClassManager::PreCallAction, dbname=CM_CAS SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    PutInstanceAsync SMS_SCI_SysResUse SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    CExtProviderClassObject::DoPutInstanceInstance SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    *~*~e:\qfe\nts\sms\siteserver\sdk_provider\smsprov\sspsitesettingitem.cpp(121) : User "Domain\jphiffer" does not have sufficient rights.~*~* SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    *~*~User "Domain\jphiffer" does not have sufficient rights. ~*~* SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    Auditing: User Domain\jphiffer called an audited method of an instance of class SMS_SCI_SysResUse. SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)
    CExtUserContext::LeaveThread : Releasing IWbemContextPtr=-1443569536 SMS Provider 9/27/2016 10:06:08 AM 4716 (0x126C)

    As I assumed it throws a permissions error.  I have verified WMI permissions to root\sms for sms admins.  Also verified console permissions using RBAviewer which list me as Full Administrator for the CAS.  I'll likely have a call tomorrow with CSS unless anyone has ideas on the above.  I'll be sure to post a solution once I have one.


    Tuesday, September 27, 2016 3:05 PM
  • What security scope do you have?

    FYI I'm at Ignite so I'm check thing off and on...


    Garth Jones

    Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

    Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

    Sorry, just noticed your post, but my Role is "Full Administrator" and my scope is "All"

    Wednesday, September 28, 2016 3:35 PM
  • I'm just getting back to this now, did you get this fixed?

    Garth Jones

    Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

    Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

    Tuesday, October 4, 2016 12:09 PM
  • No I have not. I'm still working on this issue.  I did contact MS, and they are on and off working with me on it as well.  So far we've got nothing, and the tech is trying to research the issue.
    Tuesday, October 4, 2016 2:48 PM
  • So the issue was related to the expansion of the CAS.  Originally I had a replication issue which I fixed, but apparently the replication issue marked the CAS as "Expansion Failed" and it would not retry doing the expansion without some SQL query magic.  If you run into an issue like this, it is recommended you use Microsoft CSS to help resolve.  

    To set the site status back to where it will retry site expansion, we ran the following:

    select * from serverdata

    update ServerData set SiteStatus=125 where SiteStatus=450

    select * from sites

    update Sites set DetailedStatus=125 where SiteCode='CAS'

    Obviously the last line 'CAS' will be the sitecode of your CAS.  You can find the SiteStatus that a site is currently in by looking in the console and making sure to have the column active that shows "Requested Status".  Before the fix, my CAS was in 450.  After running the commands, you could see in the SMSProv.log the progress.

    • Marked as answer by J.Phiffer Monday, October 31, 2016 1:19 PM
    Monday, October 31, 2016 1:19 PM