Tag Archives: microsoft

Create policy to put users/groups in local admin group…


i want to put ie my service account named _svc_vmmservice to the local admin group in my vmm nodes. following the microsoft AGLP (accounts->global groups->local groups->permissions) first i create a global group named “_gg_localAdminVMM” and a local group named “_lg_localAdminVMM” – put _svc_vmmservice in global group and put global group in local group:

…in addition you need a Group for VMM servers/nodes (not users) – do the same for VMM servers:

Create Policy:


…remove “Authenticated users” and change scope of this policy to VMM servers group:

…dont forget to link this GPO to your ServerOU..

time to apply this new policy with:

…you can check it with the command:

…before gpupdate:

and after gpupdate:



HINT: if you dont see your policy applied and you have created the computer group for your VMM servers a short time before – you have to reboot your VMM servers to apply the membership of the group first!

Create a policy to add local admin account – the new way…

Since Microsoft changed the security policies the “old way” via policy to create a local admin account and give them a password does not work anymore – information about this security update can be found at: https://blogs.technet.microsoft.com/srd/2014/05/13/ms14-025-an-update-for-group-policy-preferences/

if you have installed this security patch and want to create a new policy “old-way” with a new user and password – you can not type-in any passwords because the fields are greyed-out:

The new way to do this is with Microsoft´s Local Admin Password Solution (LAPS) – see: https://www.microsoft.com/en-us/download/details.aspx?id=46899

HowTo Install:

you need a Management computer for installing the management tools, powershell module,… – in addition it is useful to have also all the AD management tools (users and computers, group policy editor,..) installed on this management computer.

Download all (you will need x86 and x64 later) packages from: https://www.microsoft.com/en-us/download/details.aspx?id=46899 to the management computer and start LAPS.x64.msi – or x86 if you have a 32bit management computer (build client packages later):

..install all the features:

Policy for installing client package:

LAPS needs a dll on all the computers where laps should store and change the local admin pwd. The easiest way to do that is, create a policy for deploying this package – start group policy editor and create a new policy :

..choose the LAPS x64 package first, for deploying software to 64bit clients/servers:

…we need also the x86 package:

…i will rename the packages (looks better than (2)) – right click -> properties:

…we want to avoid that the x86 package are also distributed to x64 computers – right click on x86 package and choose properties:

…uncheck “Make this 32-bit…..”:

…i have several OUs in my AD – Resources->Computers where all Workstations and Servers reside – i will link this GPO to my Resources OU:


..unfortunately LAPS client need a reboot to complete the update – you see this after GPUPDATE /FORCE:

Extend the AD schema:

open powershell with admin rights on your management server and import the laps ps module:

…update schema:

Set/Check Permissions:

…the default permission to manage local passwords are less restrictive (Domain Users can read) – we want to change it – open ADSIEdit:

…because i have my own OU structure Resources->Computers,.. i have to right-click on ComputersOU and select Properties:

…be sure that under Security Tab are only Users that you give permissions are “All extended rights” checked – ie. Remove this checkmark from Everyone… (in Server 2016 permissions are correct (only Domain Admins, Enterprise Admins have rights), nothing to do in this OS…):

…now give all computers under your OU the permission to change their passwords for itself:

next give users the permission to read the passwords for computer in a OU (in my case ComputersOU) – you can make this very granular, ie use a AD group for workstations and another AD group for servers – Domain Admins are ok for my environment:

Create Local Password Policy:

Last step is to create a policy for changing local passwords, complexity and other – LAPS setup had installed a ADM template on your management workstation for that – so if you have also Group Policy Editor installed on this workstation open GPMC create a new policy and browse to CompConfig->Policies->Admin Templates->LAPS:


enable pwd management and change the other settings depending on your needs:

…if you have another policy that disables the local account named “Administrator” and create another user with the name ie “_adm_localAdmin” you must enable this policy setting and change the name to the name of your local admin account (if you have no policy like that and want to change the default local account named “Administrator” you can leave this as default – not configured:


dont forget to link your password policy to the appropriate OUs..

Read Passwords:

LAPS Setup installs a GUI Utility called “LAPS UI” on your management workstation:

or you find it in AD Users and Computers -> Computer Object -> Attributes (dont forget to check View->Advanced to show this tab):


Installing Highly Available SystemCenter VMM 2016 – HowTo…


if you want to install a highly available VMM you need two VM´s (to create a VMM cluster) and a extra HA SQL Server (ideally two SQL 2016 core Nodes with AlwaysOn – for installing this SQL nodes see http://mscloudgurublog.azurewebsites.net/2016/10/28/installing-sql-server-2016-core-on-windows-server-2016-core/

  • Create two VMs with a OS vhdx (optional one additional Data drive if you want to split OS and VMM in two different drives), 2 vCPUs and at minimum 4096 MB Memory (if you want to use Dynamic RAM, set Startup value to 4096MBs or more and Minimum RAM to 2048 or more, otherwise setup check will fail…) – see SystemCenter requirements: https://technet.microsoft.com/en-us/system-center-docs/system-requirements/minimum-hardware-recommendations
  • Create a cluster with this two VMs, no cluster disks necessary, don’t forget to create a witness (my preferred FileShare or Cloud Witness)

  • create a AlwaysOn Listener on your SQL cluster (you can deploy VMM in a “Common” Instance with other databases or you prefer a dedicated instance for VMM – collation should be: SQL_Latin1_General_CP1_CI_AS

  • Install ADK on both VMM nodes with the following options:
    • DeploymentTools
    • Windows Preinstallation Environment

…copy downloaded ADKSetup Files to both VMM nodes and install with GUI or unattended:

…after a few minutes check c:\temp\install.txt – the last entry should be “…Exit code 0…”:

  • Install the SQL tools in GUI mode or unattended:

  • do this on both vm nodes and restart the servers
Login Purpose Permission
DOMAIN\_svc_vmmservice SCVMM Service Account Local admin rights on VMM nodes
DOMAIN\_svc_vmmrunas Service Account for manageging Hyper-V Hosts Local admin rights on Hyper-V servers/nodes
(optional) DOMAIN\_svc_vmm2scom SCVMM to SCOM connector account SCOM Admin and SCVMM Admin role
(optional) DOMAIN\_svc_vmmtemplate Account used in templates to join Domain and run scripts while deployment you can use delegate control in AD for this account – Computer Objects/Reset Password/Validated write to DNS host name/Validated write to service principal name/Read/Write Account Restrictions (This object and all descendant objects – Create/Delete Computer Objects)
Name Members Scope Permission
gg_VMMAdmins your account/_svc_vmmservice/_svc_vmmrunas Global -
lg_VMMAdmins gg_VMMAdmins Local Put this group in local admins group on VMM nodes
AD container:

if you install VMM in HA mode you must create a container in AD to allow VMM to store their key´s. See https://technet.microsoft.com/en-us/library/gg697604(v=sc.12).aspx

open ADSIEdit.msc and connect to the domain partition of the active directory domain:

…double click on “Default namin context…” and right click on domain context:

..give it a name (ie. VMMDKM – “Virtual Machine Manager Distributed Key Management”)

…refresh the console:

…click on domain -> your container -> and check your if your container is created successfully:


…close ADSIEdit and open “Active Directory Users and Computers” – click View -> Advanced Features:

…open Properties of your container:

…add VMM service account with R/W/Create child permissions:

…click Advanced and chance permissions to all descendant objects:


In a VMM HA install the FileShare for Library must be created outside of VMM servers – you have to create a fileshare on a MS fileserver or fileservercluster (NAS or other CIFS components are not possible because VMM installing his own VMM agent on the fileserver for management purposes…)


you can choose between nonGUI and GUI VMM setup – even on server core edition:

Server core install:

change to your VMM setup path and edit the file VMserver.ini (ie: C:\VMMSetup\amd64\Setup\VMserver.ini)

call the setup with the following parameter:

check the VMMLog in C:\ProgramData\VMMLogs

Installation in GUI mode:

..start setup – choose install, click VMM server and next:

Server name -> Name of you AlwaysOn Listener

Port -> Listener Port

Instance name -> name of SQL instance

use your vmm-service account -> see “Accounts” above and the Distinguished Name of the container you created in AD before (see container above)

HINT: ..normally everything should ok – if you get an error like me (see text in screenshot) regarding the SCP in AD – maybe you have moved your Nodes in AD in another OU and forget to give the ClusterObject the permission to create Computer Objects within this OU! – see: https://technet.microsoft.com/en-us/library/dn466519(v=ws.11).aspx or see: http://www.systemcenter.ninja/2014/01/creating-service-connection-point-scp.html

..in my case i manually create the computer object (same OU as FC object) and give the failoverclusterobject Full-rights on this new object – after that i run the configurescptool.exe command (see text above) again and voila – in Cluster Manager the Role can be started with success…

On second node:

start setup (vmmsetup recognize that it runs in a cluster and that a “primary” vmm node exist):

…if you click on VMM management server in next screen you will get the following message:

…enter registration informations again:

…settings for database are greyed-out because setup reads this info from primary installed node:

…reeenter password for vmm-service:

accept all other with next and click install:

…after a while setup should finished with success:

Last step in HA install is to make the VMM DB highly-available – we installed it with the AlwaysOn Listener but the DB itself must be switched to HA with the SQL AlwaysOn Wizard – open the SQL Studio and connect to your AO Database:

…standard SQL setup for join a single DB to AO group – change recovery mode/make backup/add db to ao group:

…right click on AOgroup and select “Add Database…”:

HINT: in SQL Alvailability group dont forget to keep your SQL users on the database in sync (!) – see: http://mscloudgurublog.azurewebsites.net/2016/10/28/installing-sql-server-2016-core-on-windows-server-2016-core/ since every works perfekt until the first failover of the DB – then VMM service failed to start, because the (ie. _svc_vmmservice) user does not exist on the failover target server.

FINISH: now you have a fully highly available SCVMM installation – test it with failover of DB (nothing should happen) – and failover of VMM (an open VMM console should simple reconnecting after a few seconds)

Installing SQL Server 2016 Core on Windows Server 2016 Core



as a best practice you should create two (domain) accounts for running the sql service and the sql agent:

Login Description
_svc_sqldb SQL Server Service Account – is NOT local Admin on SQL Servers
_svc_sqlagent SQL Server Agent Account – is NOT local Admin on SQL Servers

…in addition i create a global domain and local domain group in AD for SQL Admins – put Members to the global domain group, put global domain group into local domain group (local group gets the permission for sql server –> see sql.ini file…)

Name Description
_gg_SQLAdmins Global Group – All SQL Administrators
_lg_SQLAdmins Local Group – All Glocal SQL Admin Groups

best practice for SQL servers is to put Data, Log and Temp Files in different harddrives (in physical word in different raid configs) – i prefer this also in virtual environments even if i have a config that puts all vDisks on the same physical drives – per SQL VM create 4 vDisks:

Filename Description
SystemOS.vhdx Boot Disk with OS
SQL-Data.vhdx Shared SQL Components and Instance Dirs
SQL-Temp.vhdx Drive for SQL Temp DB's
SQL-Log.vhdx Drive for SQL Log's

(see sql.ini for configuring the different drive letters and paths…)

if you want to manage your harddrives remotely by mmc plugin – you have to enable the appropriate firewall-rules on server core AND your workstation machine (if you not enable on your workstation machine you will get the error “RPC server unavailable):

check if the rules for remote disk management are enabled:


…not enabled by default – type:

…and check again: image

…if you prefer the GUI – Server Manager from Admin Workstation is great – you can use it to manage disks remotely (change disk label,…)

Hotfixes, CUs, SPs and Patches:

..while setup is running, it can implement existing updates – copy all updates in a directory named i.e C:\SQLSetup\Updates\… and refer this path in your SQL.ini

i.e. for SQL Server 2016 RTM – download CU2: https://www.microsoft.com/en-us/download/details.aspx?id=53338


…if you do not created a ini file before, you can copy this sample sql.ini and edit for your own:


..in CMD Shell on server core type:



HINT: see troubleshooting section for a bug in the setup routine – you have to add permissions on your backup dir, if you install additional instances…

after setup is finish – you have to manually create the firewall rule for accessing your instance:


per server:

per instance:

per listener (if you use alwayson):

older versions SERVER2012R2/SQL2012 (other Profile Parameter and SQL Path):

per server:

per instance:

per listener (if you use alwayson):

you can check if everything is ok with management studio – connect to the sql server\instance name and version number should be 13.0.2164 (SQL2016 with CU2) – see version numbers: https://sqlserverbuilds.blogspot.co.at/

AlwaysOn config:

…if you want to create a AlwaysOn SQL Infra – do exact the same on a second server (don’t forget to create cluster first…)

Enable AlwaysOn:

Open PowerShell with Admin Rights (if you have a fresh install and not reopened your powershell window – no SQL cmdlet will be found (!) – so don´t forget to logoff and logon before start PS)


…do this on ALL sql nodes…

HINT – AlwaysOn: if you create a AvailabilityGroup and want to use it for i.e. SystemCenter VMM – see: http://mscloudgurublog.azurewebsites.net/2016/10/30/installing-highly-available-systemcenter-vmm-2016-howto/ don´t forget that AlwaysOn does NOT sync user logins on SQL automatically – so if you install VMM every works perfect until the first SQL Failover – after that VMM services crashes, because it can not connect to your database.

Good way to keep the user´s in sync, is a great tool named dbatools – it´s free of charge and you can find it via: https://dbatools.io/getting-started/

Installation is very simple via PSGallery on your SQL server – open powershell and type:

..aswer the following questions about NuGet and so on with Yes (you need a internet connection from your server..)

Test the connection to the server you logged in and the other sql server nodes that part of your Availability Group with:

Keep users in sync type:

i will do this in a scheduled task so have a perfect solution to keep all sql user logins on all sql servers in sync.


you can find any error or information in the SQL Setup log file located in C:\Program Files\MicrosoftSQL Server\130\Setup Bootstrap\Log\ – see the reference article: https://msdn.microsoft.com/en-us/library/ms143702.aspx

HINT: …i found a  bug in the sql setup – if you install the instances with a unattended .ini file and point every instance to backup their databases to ie. E:\backup directory – the setup process create only for the FIRST instance the appropriate permissions for this directory (ie: NT Service\MSSQL$COMMON has Full permission to E:\Backup NOT other instances ie. NT Service\MSSQL$SCVMMDB…..) – to solve this open a Admin CMD Shell on every SQL node and enter:

you can check the correct permissions with:

if you have 2 instances (COMMON and SCVMMDB) it should look like this: