Overview

Start by setting up a clean install of Windows Server 2008 R2. I use the Standard edition for this purpose as I don’t expect its resource requirements to be very high. Once you have your clean install finished and are logged in as the local Administrator, launch the Active Directory installation wizard and configure the server as a Domain Controller.

Start -> Run -> dcpromo -> OK

Go through the Active Directory Installation wizard as briefly detailed below:

• Give your internal domain a name of your choice. Example: “yournamechoice.local”
• Choose a Directory Services restore mode password and note it down.
• When you arrive at the “Set Domain Functional Level” page, select “Windows Server 2008 R2″ from the dropdown list. Among other things, this will allow the “Active Directory Recycle Bin” feature should you wish. If you plan on joining other servers running older versions of Windows to this domain, then choose the correct level to support these older OSes.
• When you are asked about creating a DNS delegation to an existing DNS server, choose to continue the install by selecting “No action is required”. This will be the first DNS server on the domain as it is in theory, a “single” server.
• Finish the wizard off and choose to restart the server once complete.

Next up, we will install the RDS (Remote Desktop Services) role. This is formerly known as the Terminal Services role in previous versions of Windows Server.

Server Manager -> Roles -> Add Roles -> Remote Desktop Services

• Select the “Remote Desktop Session Host” feature.
• The wizard will warn that this is a Domain Controller and that this role is not recommended. We know that Microsoft don’t recommend this configuration, so as long as you are happy with this, select to “Install Remote Desktop Session Host anyway” when prompted.
• Select the “Remote Desktop Licensing” feature.
• Choose “Do not require network level authentication” – this option depends on how you want your security set up.
• Depending on your license model, choose the appropriate option. I almost always use “Per user license model”.
• Choose which Client Experience Features to install. i.e. Audio/Video playback, audio recording redirection and desktop composition.
• Leave the RD Licensing Configuration page on the defaults and continue.
• Complete the installation of this role, and then restart when prompted.

Now we need to activation the RDS Licensing server and install some CALs (Client Access Licenses) so that users can login to this server remotely.

Administrative Tools -> Remote Desktop Services -> Remote Desktop Licensing Manager

• If you don’t see this, you probably don’t have the Licensing role installed. Open Server Manager, Expand Roles, Right-click Remote Desktop Servers, and choose “Add Role Services”. Add the “Remote Desktop Licensing” role service. Go back and open the Remote Desktop Licensing Manager once this role service has been added.
• Right-click the server name, and select “Activate Server”.
• Complete the activation wizard using “Automatic connection” and by entering your details.
• Finish the wizard and leave the selection on to “Start Install Licenses Wizard now”.
• Choose the licensing agreement type that you are using or registered for.
• Product version should be: Windows Server 2008 / Windows Server 2008 R2
• License type should be: Per User CAL (TS or RDS) (That is if you use the per user licensing model)
• Finish the wizard and the RDS User CALs should now be installed and activated.

The next step is to specify your license server.

• Administrative Tools -> Remote Desktop Services -> “Remote Desktop Session Host Configuration”
• Right-click “Remote Desktop License Servers (Not specified)” and select “Properties”
• Ensure that “Per User” is still selected (or the license model you chose), then click the “Add” button and select the server name.
• Click Add, then OK, then OK again to close the window.
• The licensing server should now specified and be able to issue RDS CALs to connecting clients.

Next we need to allow users to login locally (This is required for the RDS role on a Domain Controller). We’ll be modifying group policy now, so open up Group Policy Management (GPMC.msc)

• Edit the “Default Domain Policy”
• Go to: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment
• The following two entries will be shown as “Not Defined” -> “Allow logon locally” & “Allow logon through Remote Desktop Services”
• Right click and enable these, specifying the following security groups in each:
• Account Operators; Administrators; Backup Operators; Print Operators; Server Operators; Remote Desktop Users.
• Exit the GP Editor then open a CMD prompt and run “gpupdate /force” You may also wish to restart the server at this point to ensure the policies are applied correctly.

Conclusion

At this point you should now have a server that provides the roles of a Domain Controller and a Remote Desktop Session Host. Active Directory users should be able to use the Remote Desktop Connection client to connect and you will be able to provision software for them to use by installing it via RD-Install mode (found in the Control Panel). The rest of the customization is up to you now, so go wild! If you have any other suggestions or ideas, please leave your comments below.

To start with you will obviously require more than one Domain Controller in your Windows domain. In my case I have a “Primary” and “Secondary” domain controller called “NOOBS-DC1″ and “NOOBS-DC2″.

Transferring roles

RID, PDC or Infrastructure roles:

Start by opening Active Directory Users and Computers on the DC you want to change the role to. Right-click your domain name and select “Operation Masters” from the context menu.

Select the tab corresponding to the role you would like to transfer. Below this you should be able to see the name of the DC you are currently on, or connected to. Click the “Change” button to change the role over to the DC listed.

Confirm the change when asked, at which point you should receive a message stating that the procedure was successful.

Remember that this method can be used to transfer any of the RID (Relative ID), PDC (PDC Emulator) or Infrastructure roles. Just select the role you want to transfer by using the relevant tab.

Domain Naming Master role

Again, start on the DC that you would like to transfer this role to. Open Active Directory Domains and Trusts, then right-click the top level that reads “Active Directory Domains and Trusts” then select “Operations Master” from the context menu.

Check that the DC listed is the machine you would like to change the role to, then click “Change”.

Confirm the change – If all went well you should now receive a message stating the transfer was a success.

Note that you can also use the “Connect to Domain Controller” option in the context menu to connect to the DC you would like to transfer the role to. Access this by right-clicking “Active Directory Domains and Trusts” and then selecting the “Connect to Domain Controller” option. Here is what the Connect to Domain Controller window should look like:

Schema Master role

The Schema master role needs a little bit of extra work to change as the MMC snap-in you use is usually hidden. We will first need to register a .dll file before we are able to access this.

Again, start on the DC you would like the change the role to. Open a command prompt window and type in “regsvr32 schmmgmt.dll” then press Enter. You should receive a message stating the .dll was registered.

Now open a brand new MMC console. (Start -> Run -> type in “mmc” then press Enter). Select “File” then “Add/remove Snap-in” and click the “Add” button. You should see our newly added snap-in called “Active Directory Schema”. Select this option, then click “Add” and then “Close”. Click the “OK” button to go to back to your MMC.

Right-click “Active Directory Schema [your DC name]” and select “Change Domain Controller” if you are not already connected to the DC that you would like to inherit the role. Specify the DC’s name and confirm. In the screenshots below, I was defaulted to being connected to the DC1 server when loading the snap-in, but wanted to change to DC2 as this was the server that was going to be receiving the “Schema Master” role.

Right-click “Active Directory Schema [your DC name]” and select “Operations Master”. Finally, click the “Change” button to initiate the change. Confirm by click “Yes”, and you should receive a success message.

That should cover the basics of transferring your five FSMO roles between Domain Controllers. In the next part we’ll take a practical look at how to seize roles using the ntdsutil.exe command.

RBAC Components

To get a basic understanding of how this is going to work, a quick description of the RBAC components used in the upcoming example will be helpful:

• Management Role – this is just a container for a group of Exchange Management Shell cmdlets. For example, the Mail Recipient Creation role contains only the cmdlets required to view, create and delete recipients.
• Management Role Entry – this is an Exchange Management Shell cmdlet or custom script. Management roles are made up of management role entries.
• Management Role Group – this is an Active Directory universal security group that contains the user accounts that can be assigned to a role.
• Management Role Scope – this can be used to filter the type of objects that can be managed, and where they can be managed in Active Directory.
• Management Role Assignment – this links a management scope to a management role.

Scenario

Let’s say that your company has decided that a group of support personnel should be responsible for the creation of all new Exchange recipients. You want to be very specific about what type of access this group will be granted, and you plan on implementing a custom management role based on the following requirements:

• Support personnel should be able to create Exchange recipients in the Employee OU in Active Directory.
• Support personnel should not be able to create Exchange recipients in any other OU in Active Directory.
• Support personnel should not be able to remove recipients in the Employees OU, or any other OU in Active Directory.

Now that the requirements are clearly defined, we are ready to implement our custom management role.

Step 1: Create the Management Role

The built-in roles cannot be changed, so we need to create a new management role using one of the built-in roles as a parent. We know that the Mail Recipient Creation role provides the cmdlets that our support group will need, so we’ll create a new role as a child of the Mail Recipient Creation role using the following command:

New-ManagementRole -Name "Employee Recipient Creation" -Parent "Mail Recipient Creation"

Step 2: Modify the Management Role

One of the requirements in our scenario was that support personnel should not be able to remove recipients, so we need to edit our custom role and get rid of any cmdlets that can be used to remove recipients:

Get-ManagementRoleEntry "Employee Recipient Creation\*" | ?{$_.name -like "remove-*"} | Remove-ManagementRoleEntry -Confirm:$false

The above command will delete all of the Remove-* cmdlets from our custom role, and therefore will prevent users assigned to this role from removing recipient objects.

Step 3: Create the Management Scope

The next step is to create a management scope that defines where and what the support group has access to. We’ll use the following command to create our Employee management scope:

New-ManagementScope -Name Employees -RecipientRoot contoso.com/Employees -RecipientRestrictionFilter {(RecipientType -eq "UserMailbox") -or (RecipientType -eq "MailUser") -or (RecipientType -eq "MailContact")}

As you can see, we are specifying the recipient root as the Employees OU, per the requirements in our scenario. When specifying a RecipientRoot, we are also required to specify a RecipientRestrictionFilter which will be limited to the UserMailbox, MailUser and MailContact recipient types.

Step 4: Create the Management Role Group

Now we are ready to create our management role group. We’ll use the New-RoleGroup cmdlet to create the role group based on our custom role and management scope using the following command:

New-RoleGroup -Name Support -Roles "Employee Recipient Creation" -CustomRecipientWriteScope Employees -Members bjacobs,dgreen,jgordon

The above command creates a role group named support, which will create a universal security group in Active Directory in the Microsoft Exchange Security Groups OU. We configure the role to use the Employees scope that was created in the previous step, limiting access to the Employees OU. Also, notice that we added three users to this group using the Members parameter.

Doing it this way automatically creates the management role assignment for us. You can view management role assignments using the Get-ManagementRoleAssignment cmdlet.

Step 5: Verifying the Configuration

At this point our work is done and we can test the configuration to make sure it is working properly. There are several steps in creating a custom role, so the first couple of times you do this it will be useful to test the configuration to make sure everything works as expected.

Logged in as a member of the Support group, launch the Exchange Management Shell. We’ll execute the following commands to create a test mailbox in the Employees OU:

$password = ConvertTo-SecureString "P@ssw0rd01" -AsPlainText -Force

New-Mailbox -Name TestUser001 -UserPrincipalName TestUser001@contoso.com -Password $password -OrganizationalUnit contoso.com/Employees

As we can see, the above command completed successfully. Now let’s try to create a mail contact. We’ll use the New-MailContact cmdlet, omitting the OrganizationalUnit parameter:

New-MailContact -Name TestUser002 -ExternalEmailAddress TestUser002@corp.contoso.com

Without specifying an OrganizationalUnit, the command attempts to create the object in the default users container in Active Directory. We can tell from looking at the error output that our management scope is working since we are unable to create objects outside of the Employees OU.

Let’s verify that our role configuration is setup correctly by trying to use one of the Remove-* cmdlets. We’ll use the following command to remove the mailbox we created in the first step:

Remove-Mailbox TestUser001

As expected, we get an error stating that the Remove-Mailbox cmdlet cannot be found, since it is not part of the Employee Recipient Creation role.

Summary

Well, we created and tested a custom role in just 5 steps, and it was actually pretty easy to do. Once you understand the basics it’s not as hard as it seems at first glance. The TechNet documentation on RBAC is very thorough and I would highly recommend reading through it to learn more.

The lastLogonTimestamp attribute is replicated across all DCs, and it’s important to understand that it does not contain the exact time and date at which the account last logged on.  Instead there is an algorithm which is used to determine when the attribute should be updated, which by default means that the timestamp in lastLogonTimestamp could be up to 14 days old.

To understand the algorithm you need to know that there is a configurable attribute in AD called msDS-LogonTimeSyncInterval, which controls the granularity of updates to lastLogonTimestamp.  By default it is not set, which means that the default value of 14 is used.  There is also some randomization involved to ensure that simultaneous updates from many accounts don’t cause large replication loads on the DCs.  The randomization factor is a random percentage of 5 days.

The algorithm means that when a user or computer logs on the lastLogonTimestamp is only updated if the current value of lastlogonTimestamp is older than ([current date] – [14 days] + [random percentage of 5 days]).  This means that the value of lastLogonTimestamp for an active account could be anything from 9-14 days old.

The last thing to know about lastLogonTimestamp is that the value is stored in UTC format as a large integer, so needs some manipulation to get into human-readable form.

Now that we understand how the attribute works we can use it to do something useful, like find all enabled computer accounts in the domain which have not logged on for 60 or more days.  PowerShell is particularly suited to this because it has built-in methods for doing the date conversions.

# Calculate the UTC time 60 days ago, in FileTime (Integer) format and convert it to a string

$LLTSlimit = (Get-Date).AddDays(-60).ToFileTimeUTC().ToString()

# Create the LDAP filter for the AD query

# Searching for enabled computer accounts which have lastLogonTimestamp older than 60 days

$LDAPFilter = "(&(objectCategory=Computer)(lastlogontimestamp<=$LLTSlimit) (!(userAccountControl:1.2.840.113556.1.4.803:=2)))"

# Create an ADSI Searcher to query AD

$Searcher = new-object DirectoryServices.DirectorySearcher([ADSI]"")

$Searcher.filter = $LDAPFilter

# Execute the query

$Accounts = $Searcher.FindAll()

# Process the results

If ($Accounts.Count –gt 0) {

# Create an array to store all the results

$Results = @()

# Loop through each account

ForEach ($Account in $Accounts) {

# Create an object to store this account in

$Result = "" | Select-Object Name,ADSPath,lastLogonTimestamp

# Add the name to the object as a string

$Result.Name = [String]$Account.Properties.name

# Add the ADSPath to the object as a string

$Result.ADSPath = [String]$Account.Properties.adspath

# Add the lastLogonTimestamp to the object as a readable date

$Result.lastLogonTimestamp = `

[DateTime]::FromFileTime([Int64]::Parse($Account.Properties.lastlogontimestamp))

# Add this object to our array

$Results = $Results + $Result

}

}

# Output the results

$Results | Format-Table -autosize

Extending this script to disable the discovered accounts is as easy as adding this code snippet to the end:

# Disable each account

ForEach ($Result in $Results) {

$ADSIAccount = [ADSI]$Result.ADSPath

$ADSIAccount.PSBase.InvokeSet("AccountDisabled", "True")

$ADSIAccount.SetInfo()

}

The lastLogonTimestamp attribute is useful for system administrators to understand, and because PowerShell can handle all the type conversions and date arithmetic, it is a great tool to use when working with it.