Several days ago Microsoft released Rollup 1 for Windows Azure Pack. The KB article describes how to update your WAP deployment.
I strictly followed the upgrade guide, and so far it went very well. But after upgrading the Admin API and Admin Site components, I was not able to launch the admin site and received a well known security message which you usually get after initial deployment when the security token of the installation account is not updated and you didn’t re-login.
As I was pretty sure that I was able to access the Windows Auth Site with the same user before the upgrade 🙂 , so I started my investigations. The RTM version of Windows Azure Pack adds the user account which is used to deploy the components to a local group on the WAP server, where the Admin API and Admin Site are deployed. The group is called : MgmtSvc Operators
Because I modified the group by removing the user and adding a AD Security Group I was comfortable to add additional WAP Admins. But hey.. where has this local group gone?
RU1 added two new local groups called WindowsFabricAdministrators and WindowsFabricAllowedUsers. While the first seems to reflect WAP Admins, the second seems to restrict Admin API connection permissions, but not sure on that yet.
Having a look at the corresponding table within the MgmtSvc database has shown me the root cause.
The previously used local group was still registered, not so the new Fabric Management groups.
Of course you could modifiy the table manually using SQL Management Studio, but it is not supported AFAIK.
I therefore used the CMDLETs Get-MgmtSvcAdminUser and Add-MgmtSvcAdminUser from the MgmtSvc Modules.
Show current WAP Admins
$connectionstring = 'Server=srvdb01.miru.local\SysCtr;Initial Catalog=Microsoft.MgmtSvc.Store;User ID=sa;Password=Some@Password' Get-MgmtSvcAdminUser -ConnectionString $connectionstring
Add a principal (group or user) as WAP Admin
$connectionstring = 'Server=srvdb01.miru.local\SysCtr;Initial Catalog=Microsoft.MgmtSvc.Store;User ID=sa;Password=Some@Password' Add-MgmtSvcAdminUser -ConnectionString $connectionstring -Principal 'DOMAIN\SecurityGroupName'
I decided to use a Domain Security Group, so I should not be affected by any changes to the local groups in the future 🙂
Beside this little hick up, the RU1 upgrade went very well and smooth.