Category: Planning for Server Management

MCTS 70-646 Plan and implement group policy strategy

Plan and implement group policy strategy

Starter Group Policy Objects (GPO)

Starter GPOs are baseline templates you can use when building GPOs. Starter GPOs can be exported to other domains too. Starter GPOs are backed up and restored using the backup all and manage backups via the starter GPOs node.

Starter GPOs can only contain administrative template settings.

Group Policy backup and Recovery

Standard group policies can be backed up and restored from within the group policy objects node.

Group Policy Strategy

The best advice with Group Policy is to keep it simple; avoid too much inheritance blocking, organisational units with lots of GPOs, many organisational units linking to the same GPO, monolithic GPOs which change frequently and implement functional GPO where necessary i.e. where changes are frequent; this will speed up the client side extension processing.

It is recommended you disable the user and computer configuration portion of a policy if it is not used; note this is unlikely to speed up processing, the group policy client still has to query Active Directory to check if that portion of the policy is disabled.

The Group Policy ADMX files should be stored in a central store this stores domain controllers storing redundant copies of the same data. The central store should be configured with sysvol; to configure the central store create a policyDefinitions folder and copy the admx policy files to it, create a en-us folder within the policyDefinitions folder and copy the adml language files.

Starter Group Policy Objects should be used to create standardised combinations of administrative templates.

Troubleshooting Group Policy

The first step is to check the core configuration i.e. the computer is connected to the network, can you ping it, can you resolve DNS names, is the system clock within the limits defined by kerberos. Some of the above checks will also test services e.g. resolving DNS confirms the DNS service is working, logging onto the domain confirms the AD DS is working. Remember the core services for group policy are AD DS, DNS and TCP/IP.

Tools such as gpotool.exe, rsop.msc and gpresult.exe can be used to verify what policies are being or not being applied. rsop.msc can point towards why policies are not applied. gpotool.exe can be used to verify policies are correct.

The operational logs within Windows event viewer are also very useful when reviewing which policies have been applied and how long they took.

When policies are not being applied or take an inordinate amount of time to apply it is always good to understand how the group policy process works.

First of all the group policy client queries the nearest Domain Controller to get a list of Group Policy Object which apply to the logged in user and computer.

Next the client side extension processing starts; the newer Windows operating systems use Network Location Awareness (NLA) to determine whether they’re within the domain or on a public internet connection. NLA uses the connection specific DNS information and the NetworkName registry key, if they’re the same the client attempts to query the domain controller using LDAP.

Once NLA deems the client computer to be in the domain the group policy client reads the CSE information from the registry then the group policy client uses LDAP to search for GPOs with the gpLink attribute.

The group policy client then checks whether the user or computer has permission to read the GPO, finally the group policy client reads the gpt.ini to determine if the policy has been updated; it uses information within the client registry to determine this.

MCTS 70-646 Plan for delegated administration

Plan for delegated administration

The main reason for delegation of administration is to give specific administrative rights to specific users or groups.

Delegated control

Delegation can be applied within AD DS by configuring access control entries on organisational units; this can be accomplished using the GUI (dsa.msc) or dsacls.exe or PowerShell Active Directory modules. Delegation can be configured using a wizard, this allows administrators to quickly apply delegation for common tasks. Alternatively you can configure the OU ACEs manually to create more granular and customised delegation. I’ve blogged previously about AD DS delegation see here Existing delegation configuration can be time consuming to troubleshoot if the delegation hasn’t been defined within a change control system for example. In this scenario you can reset the delegated settings to default. Use dsacls.exe “OU=[Name],DC=[Domain],DC=[Tld]” /resetDefaultDACL or Click default within the advanced security settings of a particular OU you wish to reset.

Group membership delegation

Group membership delegation can be configured by assigning the managed by attribute; In Windows Server 2008 this can be a group, Windows Server 2003 only allows users or contacts.

Delegated Authentication

This allows a computer to impersonate a user to access resources. When the domain and forest functional level are at least Windows Server 2003 then the computer objects have a delegation tab; this allows you to trust the computer for delegation to any service using kerberos or specific services; selecting specific services is known as constrained delegation. An account which has been marked sensitive cannot be delegated; this should be the configuration applied to administrative accounts.

Role-based Access Control (RBAC)

Microsoft products such as Exchange Server, SQL Server and System Center Operations Manager 2007 R2 have RBAC; this allows you to assign administrative privileges within an application to standard Windows accounts.

Microsoft IIS 7 and 7.5 have configuration delegation functionality allowing a web site owner or application owner to have full control over their portion of the web server within reducing security.

Authorisation Manager

Authorisation Manager allows developers to create roles and scopes for their applications; applying the principles of role-based access control. Authorisation Manager can use SQL Server databases, AD DS, AD LDS or XML to store the roles, scopes, role membership etc.

MCTS 70-646 Plan server management strategies

Plan server management strategies

Server Manager Console

Displays the roles and features that are installed on that particular computer.


servermanagercmd is the command line version of server manager but Microsoft are pushing Windows PowerShell and the ServerManager module instead.

Microsoft Management Console

Microsoft Management Snap-ins are available for all roles and features that are installed; some roles will require Remote Server Administration Toolkit (RSAT) to be installed e.g. Active Directory users and computers etc.

Emergency Management Services (EMS)

EMS allows you to connect to a system via serial using telnet or similar (Hyper terminal). EMS can be used when a computer has frozen or locked up on start up or shutdown; may be a runaway process has made the computer unresponsive.

EMS must be enabled before you need to use it, ideally before it is deployed into production. EMS is enabled using BCDEDIT.

Remote Desktop

Remote Desktop allows members of the administrators and remote desktop users group to remotely connect; this doesn’t apply to domain controllers though, only administrators can connect remotely.

Remote desktop for administration allows two concurrent connections. If the computer you’re connecting to has Remote Desktop Services installed then use /admin to connect to an administrative session; if Remote Desktop Services is not installed then /admin is not needed.

You must be a member of the local administrators group to connect to an administrative session.

More information here

PowerShell Remoting

PowerShell remoting improves classic remoting functionality; classic remoting uses remoting built into the cmdlets, the remoting technology is generally (RPC) Remote Procedure Call and (DCOM) Distributed COM. Classic remoting also uses transparent authentication i.e. it uses the credentials used to run the PowerShell code.

You can identity classic remoting cmdlets using

Get-Help * -Parameter ComputerName

Alternatively you can use:

Get-Command Where-Object {$_.Parameters.Keys -contains ‘ComputerName’ -and $_.Parameters.Keys -notcontains ‘Sessions’}

The alternative command will filter out Windows PowerShell remoting cmdlets.

Windows PowerShell remoting uses the WinRM service to execute PowerShell code in a separate session on the remote system; Windows PowerShell remoting is enabled by running Enable-PSRemoting from an elevated prompt. Enable-PSRemoting starts the WinRM service if it is not running, sets up a listener on TCP 5985 and creates a firewall exception for inbound connections.

Windows PowerShell remoting uses Kerberos Authentication by default but if you’re using a peer-to-peer network or connecting to hosts outside of your trusted domain you’ll need to define a trusted host or connect via HTTPS.

Trusted hosts can be added to the trustedhosts file using

Set-Item wsman:\localhost\client\trustedhosts * -Force

Windows PowerShell remoting uses either invoke-command, Enter-PSSession or New-PSSession; New-PSSession allows you to use implicit remoting with the help of Enter-PSSession whereas invoke-command is explicit remoting.

Remote Administration Tools for Non-Administrators

In general non-administrators should be provided with MMC console snapins to administer servers rather than giving non-administrators remote desktop access.

Another method would be Telnet; Telnet is ideal for low bandwidth connections. Telnet Server can be configured by running tlntadmn.exe once the feature has been installed.

Windows Event Logs

More on Windows Event logs can be found here.