RDGW access with Powershell

Hello everyone.

I’ve worked a bit with a redundant Remote desktop Gateway (RDGW) solution where we have 2 RDGW servers in NLB, providing a redundant access to various Remote Desktop collection. RDGW provides access without the need for VPN as it encapsulates RDP into HTTPS packets.

RDGW defines access through Client Access Policy (CAP) and Resource Access Policy (RAP). The CAP states the requirement (smart card/group membership) in order to connect through the RDGW. RAP states which resources internally are available to whom, based on group membership. RAP can provide access to either members of an AD group, members of a RDGW-defined computer group, or all resources on the network. So for a user to connect to a resource, we need both a CAP and RAP which both allows him/her access to use the RDGW and to access the resource respectively.

So when you have a redundant RDGW implementation with 2 or more RDGW servers, you need to make sure all servers have the same CAP and RAP configuration or you will have seemingly random connectivity issues for the end users. Once again Powershell saves the day.

The following script connects to each RDGW server specified and creates CAP and RAP and RDGW-computer group (if needed). It is still a work with progress with room for tuning and expanding, and as always copy with pride. The script is available here




File and DFS migration script

Currently I am in a project which will migrate several users in a large AD environment from one site to another as the current site is being decommissioned. This involves (among other things) migrating files and DFS Namespace to another file server and domain controllers and since this is a repetitive task for each department, I’ve made myself a sort of workbook in Powershell that I’d like to share with you.

This is a script which I load into an elevated PowerShell ISE, and change the input variables in the top and save a copy for each department. Then I can load the script I need, run all parameters and just mark and run selection (F8 hotkey) depending on the task at hand. The script is divided into 11 parts for tasks during preparation and during cut over. I’ve used comments to clearly divide the tasks.

To put it in perspective: The script linked will handle:

  • The department “Billing”
  • Short-reference “Bill”
  • Currently has a share named “Billing$” on the old file server
  • Linked to the DFS Namespace “\\corp.contoso.com\Bill” which is used for drive mapping.

The script will check and perform the different tasks needed to move their data to another file server and update both DFS Root Targets to the new domain controllers (which will host the namespace itself).and Folder Targets which points to the new file server.

The script can be downloaded here

Personally I found this makes it a lot easier, as the project goes on, to handle several ongoing migration jobs either in preparation or at cut over phase. It also makes sure the result is consistent and reduces the risk for failure.

As always feel free to use and customize to meet your own requirements

Active Directory disaster recovery with Windows Server Backup


Earlier I wrote a post on how to backup and restore objects in Active Directory with Windows Server Backup here:  https://pertorben.wordpress.com/2013/04/15/active-directory-backup-and-restore/

Here I used the command wbadmin start systemstatebackup -backuptarget:(path) to perform a system state backup on a domain controller and use Directory Service Restore Mode (DSRM) to recover deleted items, as was explained on Microsoft Technet. However there is one drawback to this method, and it’s that you can’t perform a disaster recovery of your AD using this backup, and by disaster recovery I mean that all of your servers are completely gone and you have nothing left except your backups. If you try to use a complete server restore with this backup, this is as far as you will get.

Disaster Recovery error

So in order to do a disaster recovery you need a backup that support this. With wbadmin you can run

wbadmin start backup -allcritical -systemstate -vssfull -backuptarget:(path):

With this backup you can boot a blank server form the 2012 R2 install media and select Repair your computer. Choose image restore and it should detect your backup if it’s available.


After the restore you have a complete server restored form the point in time of which the backup was taken. From here you can seize any FSMO roles if you need, then and start promoting more domain controllers. In a disaster recovery scenario I would rather promote new domain controllers instead of running restore on every single Domain Controller. Note that your NIC will most likely be set to default on the restored server so you may need to set the correct IP address again.

So the big question now is: Can you use this backup procedure to do a restore of a deleted object in AD, instead of a complete Disaster recovery? The answer is yes. You don’t need to have 2 backups (one of AD and one for disaster recovery). All you need is the backup from this post and follow the procedure form the post I linked at the top to restore deleted object in AD.

Branchcache demonstration, part 2

Welcome back to my Branchcache demonstration.

Configure the Hosted Cache server

Picking up where part 1 left off, the next step is to configure the host cache server, though you can implement Branchcache without this. In hosted cache mode we store the cache on a designated server in the branch office and clients can pick up cached content from here. On the server located in the branch office , just start up Powershell and run

Install-WindowsFeature BranchCache -IncludeManagementTools

Once the feature is installed you configure the server, still from Powershell with

Enable-BCHostedServer (For servers who’s not domain joined)


Enable-BCHostedServer -RegisterSCP (For domain joined, enables automatic discovery from BC-clients)

To confirm the configuration you run


You should see the status something like this


and further down


Configure the clients

As for the clients things are simply configured in Group Policy

First we go to “Computer Configuration, Policies, Administrative Templates, Network, BranchCache” and set the following settings


Setting both the Distributed cache mode and the automatic hosted cache discovery makes the client search AD for a hosted cache server. If it finds a local server then it operates in hosted cache mode, and if not then the clients switch over to distributed mode.

Next we need the firewall configured. In the GPO we navigate to “Computer Configuration, Policies, Windows Settings, Security Settings, Windows Firewall with Advanced Security”

  1. Create a new inbound rule, select “predefined” and “BranchCache – Content Retrieval (Uses HTTP)“, next twice and then “Allow the connection” and click Finish
  2. Create a new inbound rule, select “predefined” and “BranchCache – Peer Discovery (Uses WSD)“, next twice and then “Allow the connection” and click Finish
  3. In outbound rules, create the exact same 2 rules as you just did for inbound.

After the GPO is done and linked to the correct OU you can turn to your clients and run

gpupdate /force

Then the Brachcache service must be restarted, so run from Powershell

Restart-Service PeerDistSvc

And to check the status it’s


Notice that the client has detected a hosted cache server and is then set itself to use it.


So from now on the data from the file share on the content server will be cached on the hosted cache server whenever a client in the branch office access it.

Does it work?

In order to verify this I have performed the following test:

  1. On the hosted cache server, start performance monitor and load all Branchcache counters
  2. From one client copy a file from the file share on the content server to the local hard drive
  3. From another client copy the same file to its local hard drive
  4. Check the Branchcache counters on the hosted cache server that Branchcache works.

And after these steps I had the following result i Performance Monitor


“SMB:Bytes from server” is from the first copy operation where the data is copied from the content server and then cached on this server. “SMB:Bytes from cache” is the second copy operation where the clients get all the data from the cache on the hosted cache server instead of from the content server which is located in another site. Looks great! 🙂

Finally, if you want to read more aboiut deploying Branchcache I recommend you read the Branchcache Deployment Guide from Microsoft. It can be downloaded here: http://www.microsoft.com/en-us/download/details.aspx?id=30418

Branchcache demonstration, part 1

Introduction to Branchcahce

Branchcache was introduced in Windows Server 2008 R2 and it is a tool to reduce the impact of having low bandwidth between a branchoffice and a central file server. The short description would be that either a dedicated server, or the clients themselves, cache the content when a file is opened or copied across the WAN link. When the next client access the same file, most of the content is available on the LAN and the need to copy data across the WAN link is reduced, resulting in a better user experience.

If you want to read more about Branchcache you can check out my own post about it: https://pertorben.wordpress.com/2012/05/29/dfs-r-or-branchcache/

In Windows Server 2012 there has been many improvements to Branchcache. A few highlights include:

  • No limitation to number of hosted cache servers in each branch office
  • No need for a separate GPO for each site
  • No need to deploy a certificate to the hosted cache servers
  • Clients can autoconfigure between hosted cache and distributed cache mode
  • Duplicate content is only downloaded once
  • Cache is encrypted by default
  • Cache can now be pre-loaded

Full list of changes are located here: http://technet.microsoft.com/en-us/library/jj127252.aspx

Branchcache can operate in either “hosted cache mode” where a server in the branch office stores the cache, or in “distributed cache mode” where the clients store and shares the cache among themselves. Now I want to make a simple demonstration of Branchcache in hosted cache mode using Windows Server 2012 and Windows 8. First of all:

The lab setup

  • 1 domain divided in 2 sites “HQ” and “SmallOffice” (guess which one is the branch office) with a DC in each site.
  • 1 centralized file server as “content server” (the server containing the files)
  • 1 server in the branch office as “hosted cache server” (the server containing the cache of the content)
  • 2 clients in the branch office
  • All servers are Windows Server 2012, all clients are Windows 8

AD Sites is one of the key components here so make sure you define your sites and subnets correctly.

Setting up the content server

In Windows Server 2012 Powershell is dramatically expanded and improved so it’s no surprise that we use Powershell in the implementation  On the newly installed Windows Server open Powershell and run

Install-WindowsFeature FS-BranchCache -IncludeManagementTools


Next up is to enable the hash publication of the content server. Here we make a GPO and link it to the OU containing the content server. 2 simple settings located under “Computer Configuration, Policies, Administrative Templates, Network, Lanman Server”. Once it’s deployed it’s time for a “gpupdate” on the content server


After the group policy is set you have to share a folder and enable brachcache on that share. Simpe way to do so in the GUI


Now that the content server is ready I’m gonna fill it up with some files and in part 2 we will set up the Hosted cache server and the clients and I’ll do a proof of concept.

See you in part 2!

Active Directory backup and restore

UPDATE: I’ve written a related post about disaster recovery of Active Directory, I strongly recommend that you all read it. https://pertorben.wordpress.com/2015/02/21/active-directory-disaster-recovery-with-windows-server-backup/

Active Directory is one of the most central service in your infrastructure I wanted to write a quick post on how you can perform a backup and a restore, and this post will cover the basics of it. As with all other restore scenarios I think it’s very important to practice the restore procedure before you really need to restore something.

Authorative vs non-autorative restore

When you restore an object in AD then the object will we updated in the next replication run, this is because the other domain controllers have a newer version of the same object. This also means that if you restore a deleted user then the user is deleted again when replication runs. This is because a regular restore is a “non-authorative restore”. If you perform an “authorative restore” then the restores user will remain and update the other domain controllers.

Backup Active Directory

You can use Windows Server Backup to backup Active Directory quickly and easily. Note that the backup destination can’t be a local systemdrive on the domain controller. To backup AD using Windows Server Backup simply run

wbadmin start systemstatebackup -backuptarget:(path)

Directory Services Restore Mode

Every time you want to perform a restore you must boot you DC into “Directory Services Restore Mode” (DSRM). I know AD now is a service which you can stop and start, but there may be information stored in memory or other caches. Don’t cut cornes here, boot into DSRM. You need the DSRM password on your domain controller and if you find at this point that you don’t know this password or haven’t documentated it, then I strongly suggest you look into your disaster recovery plans because this is vital for disaster recovery. The DSRM password can be reset using “ntdsutil”. I recommend that you enable DSRM as the default boot option so you don’t have to struggle with F8-spamming when the server boots. You can run this command to enable boot into DSRM every time the server boots:

bcdedit /set safeboot dsrepair

Now that the server boots into DSRM every time you can safely reboot the domain controllers without fear of booting into normal mode prematurely. When you’re all done with the restore procedure and want to boot normally you can run

bcdedit /deletevalue safeboot

Also note that the shutdown.exe has a new switch: -o which lets you choose how to boot your server, though this is only the next boot and Windows Server 2012 wants an additional reboot into DSRM for doing an authorative restore. Therefore I prefer the bcdedit approach.

Performing a restore 

Before you perform an authorative restore it helps to note the Distinguished Name of the container where it resided. Then you can reboot your DC into DSRM and login using the lodal administrator account and DSRM password. Then you just use wbadmin to restore AD

wbadmin start systemstaterecovery -version:(versionnumber)

To find your backupversion use the command

wbadmin get versions

In this screenshot I’m performing a restore from backup on one of my lab DC’s using wbadmin. I’ve deleted a user named “user 1” who was a member of the group dnsadmins.


After the restore the server wants a new reboot, if you want to do an authorative restore then you have to boot straight into DSRM again to avoid having the object deleted by replication. This is why the bcdedit approach is very useful in my opinion.


After the reboot you login again with the DSRM password and you should see a popup confirming the restore has successfully completed.

Making the restore authorative

Now it’s time to run ntdsutil from a command prompt. There you must first activate the ntds instance and then then the authorative restore prompt. Here you can either restore an OU using

Restore subtree (DN of the container)

or a simple objece with

Restore object (DN of the object)

Below I make an authorative restore of the “user 1” object I have deleted earlier.


Now the next part is to fix the group memberships if the restored user is member of groups in other domains. The output in the screenshot above name a .ldf file which you can use to fix this. You don’t have to do this to restore group memberships within the same domain. Just exit ntdsutil and from the command prompt you run

ldifde -i -k -f filename.ldf

Now you can remove the boot-option for booting into DSRM and reboot your domain controller normally. The replication will make the user restored on all domain controllers with group membership intact.