The Storage Team Blog about file services and storage features in Windows and Windows Server.
Work Folders is a new component introduced in Windows Server® 2012 R2. It allows Information Workers to sync their work files between their devices. This functionality is powered by the Work Folders service that can be enabled as a Windows Server 2012 R2 File Services sub role.
Web Application Proxy is a new Remote Access role service in Windows Server® 2012 R2. Web Application Proxy provides reverse proxy functionality for web applications inside your corporate network to allow users on any device to access them from outside the corporate network. Web Application Proxy pre-authenticates access to web applications using Active Directory Federation Services (AD FS), and also functions as an AD FS proxy.
Setting up and configuring systems can be some of the most time consuming and tedious part of the job. This blog is aimed at making the deployment of Work Folders, AD FS and Web Application Proxy in Windows Server 2012 R2 to be as easy as possible.
This blog post will provide walk-through instructions on how to set up Work Folders with AD FS and Web Application Proxy (WAP) for production and test environments. The goals of the blog are:
This blog will be longer than average as one of the goals of the blog is to provide a complete documented end-to-end overview of deploying Work Folders with AD FS and WAP.
A set of powershell scripts are also provided that automate all of the steps in this blog for a Test environment, which includes creating the self-signed certs needed for AD FS and Work Folders. Once you have received your certificates (from the CA of your choice), the environment can be changed over for production use. Of course, sometimes you just want to setup an environment of product as quickly as possible without waiting to get certificates from a CA or having to setup a certificate server.
Download scripts here
The scripts will created the VMs for non-domain joined and domain joined machines using an unattended xml that is dynamically generated using values from the configuration file.
The scripts makes the deployment of the entire environment less than 12 minutes. Of course, your mileage may vary +/- a couple of minutes depending on the hardware that you are using. The test environment consists of AD FS, Work Folders, WAP and two test clients (one domain joined and another non-domain joined). Work Folders will be configured with a default Sync Share that all users added and also setup to use AD FS. The sync share will have SMB access enabled and also have the shares setup to require encryption. AD FS will be setup with the Relying Party information needed to talk to Work Folders. WAP will be setup to use the AD FS endpoints so that clients on the internet/external network can use AD FS. The scripts are also written to use remote powershell for the deployment of the environment. This means that the entire environment can be setup non-interactively from the Host machine and you do not need to log into each VM.
If you are interested in just getting to the powershell scripts and setting up your environment that way, The section on the scripts is located near the end of the blog
In this blog post, I’ll provide you with the step by step guide to set up Work Folders with AD FS and WAP. When finished, you will have a complete functioning environment configured with self-signed certificates.
To follow this step by step guide, you will need to have the following computers ready:
Download Windows Server 2012 R2 eval versions here:
Download Windows 8.1 Enterprise eval versions here:
The computers can be physical or VMs. In the event that you do not have those computers already, you can run the provisioningEnvironment.ps1 in the attached zip and it will create all of the required VMs needed, with the exception of the Domain Controller. Before running the script, be sure to edit the file vms.txt to update the network information appropriately. Instructions for editing the scripts are that the end of this blog.
Once done, you’ll have a topology that looks like the below:
This blog will focus on setting up WAP, AD FS and Work Folders and WAP. In our scenario, WAP will not being joined to the domain. WAP can be deployed either deployed to a domain or not. There are some deployments in which you need you might wish to have WAP joined to a domain such as using Windows Authentication. If you plan to use Integrated Windows authentication, the Web Application Proxy server must be joined to an AD DS domain and you must also configure Kerberos Constraint Delegation (KCD).
For setting up the environment we will setup the environment in the following order:
· AD FS
· Work Folders
· Web Application Proxy
· The domain-joined workstation and non-domain joined workstation
We are going to assume you have the following setup before you dive in.
The scripts provisionEnvironment and setupEnvironment will do the following:
· create all VMs needed for the lab
· domain join the machines that need to be domain joined
· install and fully configure the respective server roles on AD FS, Work Folders and WAP
· create and install the self-signed certificates on all appropriate machines
The end result is that you will have a completely deployed environment that is configured with self-signed certificates. The two client machines (one domain joined on Contoso corpnet and another non-domain joined on an external network) will be ready to start using Work Folders either on-premise or through WAP. All that remains is for the user to initiate the Work Folders join process.
Before beginning to install AD FS, there are two things that you should do ahead of time that will save you valuable time and make the setup process quicker.
The first item that must be setup is an Active Directory domain administrator account for the AD FS service to run under. For the test environment in the blog we will be using the default contoso\administrator account. Using the default admin account is something not recommended for production. Depending on your company polices, requesting and receiving a domain admin account may take some time, so be sure to get this done up front.
The second item that you will need to successfully setup AD FS is to have a SSL SAN certificate for server authentication. For production you will want to use a publically trusted certificate.
There are many commercial CAs from which you can purchase the certificate from. You can find the CAs trusted by Microsoft on this page: http://support.microsoft.com/kb/931125. Another alternative is to get a certificate from the company Enterprise CA.
To purchase certificate, you need to visit the CA’s website, and follow the instructions on the website. Each CA has a different procedure on certificate purchase.
For our test environment we will be using a self-signed certificate. It is important to note that AD FS does not support CNG certificates, which means that you cannot create the self-signed certificate using the powershell cmdlet New-SelfSignedCertificate. The attached zip file contains a powershell script called makecert.ps1 which will create a self-signed certificated that will work with AD FS and prompt for the SAN names that will be needed to create the certificate.
The AD FS certificate needs to be a SAN certificate with the following values:
<AD FS service name>.<domain>
The enterpriseregistration SAN is needed for Work Place join.
Change your Server IP to static IP, for this blog I’m using IP class A which is 192.168.0.160 / subnet mask : 255.255.0.0 / Default Gateway : 192.168.0.1 / Preferred DNS : 192.168.0.150 (the IP address of your Domain Controller)
To install AD FS, select the Active Directory Federation Services Role under Server Roles and click next
If you plan on using your AD FS server as part of a Hybrid Deployment and will be using DirSync, select install the .Net Framework 3.5 features. To install .Net 3.5, you’ll need to mount the Windows Server ISO as a DVD drive in your VHD.
On the confirmation page you will see a note informing you that the Web Application Proxy role cannot be installed on the same computer as AD FS. Click Next.
If you did not choose you install .Net 3.5, you’ll see a confirmation screen that looks like the below.
If you choose to install .Net 3.5, you’ll see a confirmation screen that looks like the below. Make sure to provide an alternate source path to the Windows Server 2012 R2 iso. i.e. d:\sources\SxS
If you do did not mount the Windows Server 2012 R2 iso, you’ll receive an error screen like the below and you will need to restart the entire install process for AD FS.
To accomplish the equivalent install of AD FS through powershell, use the below commands:
The next step is to configure AD FS.
Select the Warning Flag at the top of Server manager and click on the link that says “Configure the federation service on this server”.
The link will launch the Active Directory Federation Services wizard. The first page after the Welcome screen will be for the domain administrator account that will be used as the dedicated AD FS account.
Enter the subject name of the SSL certificate to be used for AD FS communication and set the name of the Federation Service Name. It is important to note that for the Federation Service name to not use the name of an existing server in the environment. If you do use the name of an existing machine, the AD FS installation will fail and will need to be restarted again.
Enter the name that you would like to be used for the Managed Service Account.
Select use the Windows Internal Database and press Next.
The review screen will show you an overview of the options you have selected. Press next.
The next screen will be the Pre-requisites check page. If everything shows as good, press Configure.
If you did you the name of the AD FS server or the name of another existing machine, you’ll receive the below error message. You should start the install over and choose a name other than the name of the AD FS machine or any existing machine.
When the configuration completes successfully you’ll see the below screen indicating that AD FS was successfully configured.
Here’s how to accomplish the same via powershell:
Setup the AD FS Farm
Setting up the AD FS will use the Managed Service account used above and the certificate you created in the pre-configuration steps.
There are four post configuration work after setting up and configuring AD FS. They are:
You will need to create two DNS entries for AD FS. These are the same two entries that were used in the Pre-Configuration steps when the SAN certificated was created.
e.g. for our setup
On your DC, open up the DNS manager
Expand the Forward Lookup Zones, right click on your domain and select New Host (A).
The New Resource Record form will open. Enter in the alias for AD FS in the Alias name field. In the lab case it will be “blueadfs”. The alias must be the same as what was used as the subject in the certificate used for AD FS earlier. Ie. If the subject was adfs.contso.com, then the alias entered here must be adfs. In the IP field, enter the IP address for the AD FS Server, i.e 192.168.0.160.
It’s *important* to note that when setting up AD FS via the UI instead of via powershell, you must create an Arecord instead of a CNAME record. The reason is that the SPN that gets created via the UI will only contain the alias that is used in setting up the AD FS Service as the HOST/.
In the powershell script, we created the SPN by including the alias as the HOST/ but also include setting two HTTP/ entries. These entries allow the SPN to redirect from the alias to the host machine.
Add in another alias (New Alias (CNAME) )name for the ‘enterpriseregistration’ cname. This ‘enterpriseregistration’ alias is used for Device Join and must be called ‘enterpriseregistration.
The powershell command to accomplish the above is below. The command must be executed on your Domain controller.
Add-DnsServerResourceRecord -ZoneName "contoso.com" -Name blueadfs -A -IPv4Address 192.168.0.160
We can setup/configure the Relying Trust for Work Folders, even though Work Folders has not been setup yet. The Relying Trust must be setup for Work Folders to use AD FS. Since we’re setting up AD FS, it is a good time to do this step.
Select AD FS Management
On the Right panel, under Actions, click on Add Relying Party Trust Wizard
The first page of the Wizard is a Welcome screen. Click Next to start the wizard
Select Enter data about the relying party manually
Enter “WorkFolders” In the Display name field and click Next.
Select the AD FS profile option for creating the relying party trust.
Click Next on the Configure Certificates page. These certificates area used as the optional token encryption certificates, and not needed for our configuration.
On the “Configure URL” screen, just click next.
On the “Configure Identifier page”, set the Target identifier to
. This identifier is a hard coded value used by Work Folders, and is sent by the Work Folders service when it is communicating with AD FS.
Click Next on the Configure Multi-factor authentation page.
On the Issuance Authorization page, select “Permit all users to access the relying party”
Click Next on the Read to Add trust page.
After the configuration is finished the last page of the Wizard will display and show that the configuration was successful.
Select the checkbox for editing the Claims Rules and press close.
The Edit Claim Rules form will now open.
In the Claim Rules type, select “Send LDAP Attributes as Claims”
On the Transform claim page, do the following:
Do the following:
Display Name –> Name
Surname –> Surname
Given-Name –> Given Name
Click Finish when done and you’ll now see your new rule showing up in the Issuance Transform rules page.
Next, click the Issuance Authorization Rules tab and you’ll see that the rule for access is set to “Permit Access to All Users”
Once all this is done, we need to finish the configuration by running four commands in PowerShell. This four commands set needed for Work Folders to successfully communicate with AD FS. These options on the Relying Partying cannot be set through the UI. The options
To enable device registration for Work Place join, you will need to run the following three powershell calls, which will configure device registration and set the global authentication policy.
The self-signed AD FS certificate will need to be exported and installed on the following machines in the test environment:
To export the certificate:
· 1. Click Start, and then click Run.2. Type MMC.3. On the File menu, click Add/Remove Snap-in.4. In the Available snap-ins list, select Certificates, and then click Add. The Certificates Snap-in Wizard starts.5. Select Computer account, and then click Next.6. Select Local computer: (the computer this console is running on), and then click Finish.7. Click OK.8. Expand Console Root\Certificates (Local Computer)\Personal\Certificates.9. Right-click Certificates, click All Tasks, and then click Export...
Go through the Certificate Export Wizard
Export the private key
Use the default options
Enter in a password for the certificate. Remember what password you use as you’ll need to use the pass later when you import the certificate to the other devices.
Enter in a location and name for the certificate and then finish the wizard.
The AD FS service account needs the permissions to access the private key of the new certificate. You should do this again when you replace the communication certificate after it expires. To do this, follow these steps:
1. Click Start, and then click Run.
2. Type MMC.
3. On the File menu, click Add/Remove Snap-in.
4. In the Available snap-ins list, select Certificates, and then click Add. The Certificates Snap-in Wizard starts.
5. Select Computer account, and then click Next.
6. Select Local computer: (the computer this console is running on), and then click Finish.
7. Click OK.
8. Expand Console Root\Certificates (Local Computer)\Personal\Certificates.
9. Right-click Certificates, click All Tasks, and then click Manage Private Keys.
10. Add the account that is running the AD FS Service, and then give the account at least read permissions
If you do not have the option to manage private keys, you may have to run the following command:certutil -repairstore my *
In your browser window, if you can see the federation server metadata without any Secure Socket Layer (SSL) errors or warnings, your federation server is operational.
2. You can also browse to the AD FS sign-in page where your federation service name is appended with adfs/ls/idpinitiatedsignon.htm, for example, https://blueadfs.contoso.com/adfs/ls/idpinitiatedsignon.htm. This entry displays
For our test environment, we have joined the VM that will be running Work Folders to the Contoso domain and setup the network interface as below. If you are setting up VMs, remember that the Default Gateway is the IP address of the Virtual Network adapter on the Host Machine (192.168.0.1 in our case)
Change your Server IP to static IP, for this blog I’m using IP class A which is 192.168.0.170 / subnet mask : 255.255.0.0 / Default Gateway : 192.168.0.1 / Preferred DNS : 192.168.0.150 (the IP address of your Domain Controller)
Create the cname records on AD for Work Folders
Expand the Forward Lookup Zones, right click on your domain and select New Alias (CNAME)
The New Resource Record form will open. Enter in the alias “workfolders” in the Alias name field. In the Fully qualified domain name field, enter the fully qualified domain for the Work Folders Server, i.e 2012R2-WF.contoso.com
1. Click Start, and then click Run.2. Type MMC.3. On the File menu, click Add/Remove Snap-in.4. In the Available snap-ins list, select Certificates, and then click Add. The Certificates Snap-in Wizard starts.5. Select Computer account, and then click Next.6. Select Local computer: (the computer this console is running on), and then click Finish.7. Click OK.8. Expand Console Root\Certificates (Local Computer)\Personal\Certificates.9. Right-click Certificates, click All Tasks, and then click Import.
1. Copy the file makeCert.ps1 to the AD FS machine.
2. Open a Admin PowerShell window
3. Set the execution policy to unrestricted
PS C:\temp\scripts> Set-ExecutionPolicy -ExecutionPolicy Unrestricted
4. Change to the directory where the script was copied
5. Execute the makeCert script
PS C:\temp\scripts> .\makecert.ps1
6. When prompted to change the subject certificate, enter the new value for the subject. In our case it will be workfolders.contoso.com.
7. When prompted to enter SANS, enter Y and then enter the SAN names (one at a time)i.e. workfolders.contoso.com <return> 2012R2-WF.contoso.com <return> . When all of the SAN names have been entered, press return on an empty line
8. When prompted to install the certificates to the Trusted Root Certification Authority, press Y
The Work Folders certificate needs to be a SAN certificate with the following values:
Start the "Add Roles and Features Wizard” and select Next.
Select Role-based or feature based installation
Select the current server and press Next.
On Server Roles, open the File and Storage Services Role, expand the File and iSCSI Services role and select Work Folders.
Optionally also install the IIS Management tools. These tools will provide some powershell management scripts that will make binding the Work Folders certificate easier. Binding the Work Folders certificate to the port being used for SSL will require using powershell or the cmdline.
One the Role Services page for IIS, just enable the Management scripts and Tools.
On the confirmation page, press Install
After Work Folders has been installed, we will need to complete the setup by configuring Work Folders.
Open Server Manager, Select File and Storage Services and Work Folders.
Click on the link in the Work Folders window to create a sync share.
Click next on the first screen.
Select the server and enter a path for the Work Folders data to be stored.
If the path does not exist, you’ll be prompted if you want to create it.
On the User Folder Structure page, select User alias and then press Next
On the Sync Share Name tab enter the name for the sync share. For our example we used “WorkFolders”. Press Next
On the Sync Access page, add in the users or groups to have access to the new Sync Share. For our example we have granted access to all domain users. Press Next when done.
On the Device Policies page, select Encrypt Work Folders and Automatically lock screen and require a password. Press Next.
On the Confirmation page, press Create to finish configuring Work Folders.
To finish setting up Work Folders there are two additional steps that will need to be done.
· Binding the Work Folders cert to the SSL port
· Configuring Work Folders to use AD FS authentication
· Exporting Work Folders certificate (if using a self-signed certificate)
Work Folders only communicates over SSL and will need to have the self-signed cert created earlier (or your CA issues certificate) bound to the port.
To bind the certificate to the port by powershell there are two methods. One method is to use the IIS cmdlets and another is to use nethsh
To use netsh in powershell you need to pipe the command to netsh . Below is an example that will find the cert with the subject, “workfolders.contoso.com” and bind it to 443 with netsh
A second way that it can be done is with the IIS management cmdlets, which can be used if you installed the web-management tools and scripts. Note that this does not enable full IIS on the Work Folders machine and only enables the management cmdlets. There are some possible benefits towards doing this, say if you are looking for cmdlets to provide what you get from netsh.. When the cert gets bound to the port via the New-WebBinding cmdlet, it is bound to the port and the binding is not dependent on IIS in any way. After doing the binding you can even remove the Web-Mgmt-Console feature and the cert will still be bound to the port, and verifiable via netsh by typing netsh http show sslcert.
Below is an example that works with Work Folders using New-WebBinding that will find the cert with the subject, “workfolders.contoso.com” and bind it to 443
To configure Work Folders to use AD FS for authentication you will need to open Server Manager. Select Servers, select your Server in the main panel and right click on the Server to bring up the context menu. On the context menu select Work Folders Settings.
On the Work Folder Settings window, select Active Directory Federation Services and type in the Federation Service URL and click apply. In our example it is
The cmdlet to accomplish via powershell is:
Set-SyncServerSetting -ADFSUrl "https://blueadfs.contoso.com"
If you are setting up AD FS with self-signed certs, you may receive the below error message about Federation Service URL being incorrect, unreachable or a relying party trust has not been setup.
This error can also happen if the AD FS cert has not been installed on Work Folders or if the CNAME for AD FS was not setup correctly.
The self-signed Work Folders certificate will need to be exported and installed on the following machines in the test environment:
10. Expand Console Root\Certificates (Local Computer)\Trusted Root Certification Authorities\Certificates.11. Right-click Certificates, click All Tasks, and then click Import.
On the Server that you plan to install the Web Application Proxy, open Server Manager and start the Add Roles and Features Wizard.
Click Next on the first page of the wizard
Click Next on the Second page of the wizard
Select you server on the third page of the wizard and click Next
On the Server Roles Page, select the Remote Access Role
On the Role Services page, select Web Application Proxy
A confirmation dialogue will immediately pop-up, press Add Features.
To configure the Web Application Proxy, select the Warning flag at the top of Server Manager which will show a link to open the Web Application Proxy Wizard
On the Welcome screen press Next
On the Federation Server enter the address of the Federation Service name. For our example it is blueadfs.contoso.com.
The wizard also asks for the credentials of local administrator account on the federation service account. Do not enter in domain credentials i.e. contoso\administrator, but local credentials i.e. just administrator
On the AD FS Proxy certificate page, select the AD FS certificate that was imported earlier and press Next.
In our case it is blueadfs.contoso.com
A confirmation page will display showing the powershell command that will execute to configure the service. An option for enabling the Web Application proxy to use OAuth is not available through the Wizard and needs to be done via powershell. The step is shown in the post-configuration section.
If OAuth is not enabled on the Web Application Proxy, your clients connecting to the Web Application Proxy will receive an error stating that the “Data in the stream is not in the proper format (0x80c81000)”
The results page will display once configuration is complete. Close the window.
The next step is to publish the Work Folders Web Application.
On Server Manager, go to Tools, Remote Access to open the Remote Access Management Console.
Select Web Application Proxy under configuration on the left side of the management console and then click Publish under Tasks on the right. The Publish New Web Application Wizard will open.
On the Welcome page, click Next.
On the Preauthentication page of the Wizard, select Active Directory Federation Services.
On the Relying Party, Select Work Folders and press Next. This list is published to the Web Application proxy from AD FS.
On the Publishing Settings page, enter the following:
By default, the wizard will make the back-end URL the same as the external URL.
For our example we will use the following values:
External URL: https://workfolders.contoso.com
External certificate: the Work Folders certificate installed earlier
Backend server URL: https://workfolders.contoso.com
External URL: https://workfolders.contoso.com
External certificate: the Work Folders certificate installed earlier
Backend server URL: https://workfolders.contoso.com
The confirmation page will show the equivalent powershell script to do the configuration. Press Publish to finish publishing the Work Folders Web Application.
If the publishing is successful, you’ll see a confirmation page like below.
To finish setting up the Web Application Proxy there is one additional step that must be done. The Web Application Proxy must be configured to use OAuth. To do so, open up an admin powershell window on the Web Application Proxy machine and execute the following command.
For our example, use the following command.
As mentioned earlier, failure to do so will cause applications connection through the Web Application Proxy an error that “Data in the stream is not in the proper format (0x80c81000)”.
Open Control Panel and select Work Folders.
Select Set up Work Folders
Work Folders can then be setup using either the user’s email address (email@example.com) or with the Work Folders URL (https://workfolders.contoso.com). Setup up Work Folders by the mechanism of your choice and press Next.
You will then be presented with a credentials prompt from AD FS. When on-prem, the prompt will be done using Windows Integrated Authentication. The challenge screen from off-prem clients will be with OAuth and users will see a different screen.
After you have authenticated, the Introducing Work Folders windows will display. On this page you can change the Work Folders document location. Press Next.
You will then see a window displaying the security policies that we had setup on Work Folders. Press Next.
You will then see a message that Work Folders has started syncing with your PC. Press Close.
The manage Work Folders panel will open showing you the amount space, sync status, etc. On this panel you can re-enter your credentials if needed. Go ahead and close the window.
Your Work Folders folder will also automatically open. From here you can start adding content to sync between your devices. We’ll go ahead and add in a Test file on the domain joined machine and setup Work Folders on our non-domain joined machine.
The hosts file on the non-domain joined client will need to be updated for our demo environment.
The hosts file will need entries put in for:
For our example we will put in the following values:
You will then be presented with a credentials prompt from AD FS. The challenge screen for the non-domain client will be using OAuth and be different from what users will see on-prem.
Your Work Folders folder will also automatically open. From here you can start adding content to sync between your devices. What you will also see is that the file from our domain joined PC has already synced to the device.
And that’s it for setting up Work Folders, AD FS and WAP from the UI (mostly ).
The attached scripts will enable to you setup and deploy the entire environment is less than 30 minutes. If you already have VMs/machines setup (i.e. domain joined, network setup, etc), then the configuration is less than 12 minutes. The whole process is IO bound so your mileage may vary. A colleague of mine has a very powerful laptop (i7 ivy bridge with 32gb of memory and a SSD) and his setup time is less than 4 ½ minutes.
The scripts were written with the assumption that you are starting from a clean environment and already have a DC setup. The scripts are designed to run from the VM Host machine and use remote powershell to configure all of the machines in the environment, so you do not need to remote into any of the machines to set them up.
There are three main steps/scripts to execute:
· setHostNetworkAdapters.ps1 – this will setup the Virtual Switches on the Host and configure the virtual network adapters as the default gateway for each network
· provisionEnvironment.ps1 – this will create the VMs needed for the environment from the downloaded ISOs and also finish setting up the OS on each machine, which includes setting the VMs network addresses and domain-joining where appropriate using unattended xml files
· setupEnvironment.ps1 – this will setup and configure AD FS, Work Folders, WAP and the two client machines.
For the scripts, the IP address of the DNS server is set to 192.168.0.150. If your DC has a different IP address you will need to update the scripts accordingly
The script setHostNetworkAdapters.ps1 will create the virtual switches on the Host machine and also set the IP address, subnet and DNS address.
The network adapters should be setup as the gateway address for each of their respective virtual networks. This enables the Host to access the VMs and vice versa. This is essential to run remote powershell scripts from host against the VMs on the network.
The script has a function called setNetworkAdapter that will setup a virtual switch and configure it’s IP addresses, subnet and DNS values.
To call the function you will need to pass in:
· Name of switch to create
· IP address to use as the gateway (the gateway IP should be the first available address in the network, i.e. XXX.XXX.XXX.1)
· The octet for the subnet
· IP address of the DNS server (optional, but should be configured on the VM network where the DC will reside)
The script is currently configured to create switches for Contoso and Fabrikam
After running the scripts, the virtual switches will be created and the network adapters will be configured.
If you already have a DC deployed, then you most likely already have at least one virtual switch and network setup. If that is the case, check to ensure that the IP address on the network adapter that the host is using for the Virtual network is configured as a gateway.
The script provisionEnvironment.ps1 will:
· Create a base referencing for disks for the Server and Client VMs. The Server base disk will be loaded with Windows Server 2012R2 Datacenter and the Client base disk will be loaded with Windows 8.1 Enterprise.
· Configure the network adapter(s) on each VM
· Domain join – where appropriate
· Enable CredSSP on each VM
You must run this script from a powershell window with Admin privileges or it will not work.
The first time that the script is run, it will take about 8 minutes to create each base differencing disk. On subsequent runs, you can reuse the previously created base VHD with no issue.
After the provisioning is complete you will have a set of differencing disks that look like the below. If you wish to recreate the environment, you can delete the differencing disks based off the base disk and reuse the existing base disk. The base disk is clean and only contains the OS.
The setup and configuration of the VMs is done with an unattended XML file that is loaded onto each VM after
Enabling CredSSP is done by creating and pushing a SetupComlete.cmd file into the directory Windows\Setup\Scripts . When the VM boots, it will execute the setupcomplete.cmd file
The script obtains the list of machines to build and the VM information from a csv file called vms.txt.
Here is what the file looks like.
Here is the definition of the csv structure
Key value to identify row
Is the machine a Server, Y= yes, N=no
Is the machine Domain Joined, Y=yes, N=no
Amount of memory in MB
Name of network to use for VMs first network adapter
IP address to use for the VMs first network adapter
DNS address to use for the VMs first network adapter
Name of network to use for VMs second network adapter (optional)
IP address to use for the VMs second network adapter (optional)
DNS address to use for the VMs second network adapter (optional)
In the script there are also variables that are used for:
The script configureEnvironment.ps1 will:
· Enable CredSSP on all domain joined Servers
· Configure AD FS, Work Folders and WAP
· Configure the two Windows 8.1 clients (one domain joined and one non-domain joined)
When the script is finished, you will have an environment that looks like the below
The script obtains the list of machines to build the servers from in a csv file called servers.txt.
Key value to identify row, do not change
FQDN of the machine
IP address of the VMs first network adapter
IP address of the VMs second network adapter (optional)
The script obtains the list of machines to build the clients from in a csv file called clients.txt.
Bios name of the machine
The setupadfs function will
The SAN values for the AD FS certificate are read from the csv file named adfssans.txt. The SAN values for the certificate must contain the AD FS service name and one for enterpriseregistration.
<ADFS Service name>.<domain>
The values in the shipped csv are
The setupWF function will
The SAN values for the Work Folders certificate are read from the csv file named wfsans.txt. The SAN values for the W certificate are read from the csv file named adfssans.txt. The SAN values for the certificate must contain the Work Folders: workfolders.<domain>
The setupWAP function will
The values for the Web Application Proxy setting are obtained from the csv file named webapps.txt. The structure of the file looks like this
Value to use for the Web App name
URL to use for the External address
URL to use for the Internal address
name of the AD FS relying party
The subject of the certificate to be used for the Web Application
The setupWorkstation function will
· install the AD FS and Work Folders certificates into the workstation VM
· Disable check for server certificate revocation. This only needed to be done for Work Place join when using self-signed certificates
If the workstation is not domain joined, the function will also update the hosts file on workstation for:
And have them point to the IP address of the WAP server.
For our example it will put in the following values:
I hope this blog post helps you to get started with AD FS, Work Folders and Web Application Proxy in your test labs and gets you a step closer to a production deployment.
Lots of good information, thank you Michael.
Outstanding post Michael! This is like a min-book. How long did this take you to write?
I have used the scripts - it is amazing how simple it is to create the environment, tear it down and recreate. Excellent work Michael
Wow, an encyclopedic post covering everything from downloading the servers, setting up the environment, the AD FS, the Certs (where I always have issues), the proxy and examples of the script.I see a book deal in our future. :)
Excellent tutorial. I set up a Lab environment with the topology above and followed all the tutorial, but I have problem getting internet on my Contoso workfolder, Contoso dc and Adfs server. My edge (Web application Proxy) has two network cards, one facing internet (WAN) and the other Contoso Network(LAN).DMZ(WAP)internet facing card IP: 192.168.0.254Contoso Network IP: 10.0.0.10Note: I have a single entry point to the Internet. How can I configure my edge (Web application Proxy) server to allow internet to my Contoso network?I will be glad if you or anyone can help me out.Regards
Is there any best practice guidance on establishing either AD in the perimeter OR domain joining WAP.. In other words.. your post uses WAP as multi-homed (dangerous IMO) I would rather see Best Practice on how to either do cross forest trust or domain join WAP .. but what all ports need to be opened for that host (DMZ DC or WAP) between the DMZ and internal networks??? I can only find old documentation on some of this (firewall = swiss cheese).. but yet claims based apps need to use constrained delegation ... Any help would be appreciated..