Tag Archives: Office 365

How to hide users from the GAL in Office 365 synchronized from on-premises

Hiding users from the Global Address List (GAL) is a fairly straight forward when the user is a cloud account. Simply "Hide from address list" from the Exchange Online console or run some quick powershell:

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session 
Set-Mailbox -Identity [email protected] -HiddenFromAddressListsEnabled $true

Hiding users from the GAL is fairly straight forward when the user is synchronized from on-premises as well.  Simply edit the attribute of the user object, set msExchHideFromAddressLists  to True, and do a sync.  The problem though is what happens if you don't have the msExchHideFromAddressLists attribute in Active Directory?

Well, you can either extend your Active Directory Schema for Exchange, which is not something that you can easily roll back if something goes wrong and arguably adds a ton of attributes that likely will be never used.  Or, you can simply create a custom sync rule within Azure AD Connect that flows the value from a different attribute.

This article will go over how to sync a custom attribute from on-premises to Azure AD to hide a user from the GAL, without the need of extending your Active Directory schema.  In this case, we are going to use an attribute called msDS-cloudExtensionAttributeX (where X is the number of the attribute that is free/not being used within your directory).  The msDS-cloudExtensionAttribute(s) were introduced in Windows Server 2012 and has 20 different numbers to allow flexibility for these types of scenarios.  Now some customers may gravitate towards using a different attribute like showInAddressBook.  The problem with the showInAddressBook is this attribute is referenced by very old versions of Exchange (which I'm sure people would never be running 😉 ) and is looking for the format of the common name of an object (not what we want).  In this case, easiest way to move forward is to simply use the msDS-cloudExtensionAttributes.

Step 1: Scope in the msDS-cloudExtensionAttribute for Azure AD Connect

Open the Azure AD Connect Synchronization Service

Navigate to the Connectors tab, select your Active Directory (not the domain.onmicrosoft.com entry), and select Properties

In the top right, click on Show All, scroll down and find msDS-CloudExtensionAttribute1 (you can use any of the numbers 1-20, just make sure to check the box you are using), and select OK

Step 2: Create a custom sync rule

Open up the Azure AD Connect Synchronization Rules Editor

Click on the Add new rule button (make sure direction in the top left shows Inbound)

Enter the following for the description:

Name: Hide user from GAL
Description: If msDS-CloudExtensionAttribute1 attribute is set to HideFromGAL, hide from Exchange Online GAL
Connected System: Your Active Directory Domain Name
Connected System Object Type: user
Metaverse Object Type: person
Link Type: Join
Precedence: 50 (this can be any number less than 100.  Just make sure you don't duplicate numbers if you have other custom rules or you'll receive a dead-lock error from SQL Server)

Click Next > on Scoping filter and Join rules, those can remain blank

Enter the following Transformation page, click the Add transformation button, fill out the form with the values below, and then click Add
FlowType: Expression
Target Attribute: msExchHideFromAddressLists
Source:

IIF(IsPresent([msDS-cloudExtensionAttribute1]),IIF([msDS-cloudExtensionAttribute1]="HideFromGAL",True,False),NULL)

 

Step 3: Perform an initial sync

Open up Windows PowerShell on the Azure AD Connect Server

Execute the following command: Start-ADSyncSyncCycle -PolicyType Initial

Step 4: Hide a user from Active Directory

Open Active Directory Users and Computers, find the user you want to hide from the GAL, right click select Properties

Select the Attributes Editor tab, find msDS-cloudExtensionAttribute1, and enter the value HideFromGAL (note, this is case sensitive), click OK and OK to close out of the editor. 

Note: if you don't see the Attribute Editor tab in the previous step, within Active Directory Users and Computers, click on View in the top menu and select Advanced Features

Step 5: Validation

Open the Azure AD Connect Synchronization Service

On the Operations tab, if you haven't seen a Delta Synchronization, manually trigger the Delta sync to pick up the change you made in Active Directory

 

Select the Export for the domain.onmicrosoft.com connecter and you should see 1 Updates

Select the user account that is listed and click Properties.  On the Connector Space Object Properties, you should see Azure AD Connect triggered an add to Azure AD to set msExchHideFromAddressLists set to true

There ya have it!  An easy way to hide users from the GAL with minimal risk to ongoing operations.  Due to the way Azure AD Connect upgrades, our sync rule will persist fine during regular updates/patches released.

Upgrading DirSync to AADSync for Office 365 and Azure environments

As of 11/11/2014, Microsoft has released their next generation tool for providing synchronization between an on-premise Active Directory environment and Microsoft based cloud service (Azure, Office 365 Suite (Lync Online, CRM, SharePoint, Exchange, etc.)).  The utility is now referenced as Microsoft Azure Active Directory Sync Services (AADSync).

In this tutorial, we will go over the process to ensure you are on the new generation of their synchronization tool.  The process is fairly straight forward, uninstall the old DirSync utility, install the new AADSync utility.  If you wish to install the utility on a new server, stop the DirSync service, install the AADSync utility on the new server, and then uinstall DirSync after you have verified synchronization is successful on the new machine.

Here is the uninstall DirSync and install AADSync process

  1. Download a copy of the AADSync utility from Microsoft's website: http://www.microsoft.com/en-us/download/details.aspx?id=44225
  2. Login to the server currently running DirSync
  3. Open up Control Panel
    Server - Start Menu - Control Panel
  4. Select Programs and Features (notice I am in the View By Small icons view)
    Control Panel - Small Icons - Programs and Features
  5. Uninstall the Windows Azure Active Directory Sync tool
  6. Select Yes to uninstall when prompted
    Windows Azure Active Directory Sync - Another instance dialog - Uninstall
  7. Uninstall Forefront Identity Manager Synchronization Service if it wasn't uninstalled already
    Uninstall - Forefront identity Manager Synchronization Service
  8. Run the MicrosoftAzureADConnectionTool.exe application you downloaded from Microsoft
    MicrosoftAzureADConnectionTool Installer
  9. Check I agree to the license terms and click Install
    Microsoft Azure Active Directory Sync Services - Install
  10. Once the install has finished, open up Computer Management and navigate to System Tools -> Local Users and Groups, Groups, and double click on ADSyncAdmins
    Computer Management - Local Users and groups - Groups - ADSyncAdmins
  11. Ensure your user account, user group, or local machine has been added to the security group
    ADSyncAdmins - Group Membership
  12. Log out of Windows
    Windows 8-Server 2012 - Sign Out

    1. Note: This step is needed to ensure you have proper user privileges when running the sync tool.  When running through the sync tool's installer, your user account will automatically be placed in a local security group called ADSyncAdmins.  A logout is needed to update your session otherwise you may receive the following error message:
      Your account is not a member of the ADSyncAdmins security group.  If you have recently installed Azure AD Sync, sign out before running this installation guide again.
      Microsoft Azure Active Directory Sync Services - Your account is not a member of the ADSyncAdmins security group
  13. Upon login, open up the DirectorySyncTool application
    DirectorySyncTool
  14. Enter your Azure or Office 365 admin credentials and click Next
    Microsoft Azure Active Directory Sync Services - Azure AD Credentials
  15. Enter in your forest name, username (must be in domain\username format), and password (Active Directory on-premise credentials) and click Add Forest
    Microsoft Azure Active Directory Sync Services - AD DS Credentials

    1. Note: If you are unsure what your forest name is, login to your domain controller and execute the following powershell command to list all forests in your deployment:
       Get-AdForest | FT Name
  16. Click Next once your forest has been validated
    Microsoft Azure Active Directory Sync Services - AD DS Credentials - Forests Validated
  17. Click Next on User Matching
    Microsoft Azure Active Directory Sync Services - User Matching
  18. Check the boxes that are applicable to your deployment and click Next
    Microsoft Azure Active Directory Sync Services - Optional Features
  19. Click Configure
    Microsoft Azure Active Directory Sync Services - Configure
  20. Click Finish
    Microsoft Azure Active Directory Sync Services - Finish

 

Office 365 - Renew your certificates (on-premise ADFS) alert

Symptom: After you replace your SSL certificates on your ADFS servers you continue to receive the following alert inside of the Office 365 portal.

Renew your certificates
One of your on-premises Federation Service certificates is expiring.  Failure to renew the certificate and update trust properties within XX days will result in a loss of access to all Office 365 services for all users.  Update now

Office 365 - Alert - Renew your certificates

Solution: This error can be caused if any of the three primary SSL Certificates that are required to federate to an external identity are nearing their experation date (Service Communications, Token-decrpting, and Token-signing).

Verify which SSL certificate is about to expire

  1. Login to your primary ADFS server
  2. Open up Server Manager
    Server 2012 R2 - Server Manager
  3. Select Tools -> AD FS Management
    Server Manager - Tools - AD FS Management
  4. Under AD FS expand Service and select Certificates
    AD FS Management Console - AD FS - Service - Certificates
  5. Verify if any certificates are set to expire
    1. Note: In this case, you can see the Token-decrypting and Token-signing certificates are set to expire soon

Replace the expir(ed)(ing) certificates

Unfortunately, I don't currently have a tutorial on the processes behind replacing each certificate.  The process for replacing each certificate is a tad different.  Here are a few articles that might help you:

Replacing the Service Communication certificate: http://blogs.technet.com/b/tune_in_to_windows_intune/archive/2013/11/13/replace-certificates-on-adfs-3-0.aspx

Replacing the token-signing and token-decrypting certificates can be found here: http://social.technet.microsoft.com/wiki/contents/articles/2554.ad-fs-2-0-how-to-replace-the-ssl-service-communications-token-signing-and-token-decrypting-certificates.aspx#Replacing_the_Token-Signing_certificate

Update the federated trust with Office 365

  1. Once your certificates are not nearing their experation date, open up the Windows Azure Active Direcotry Module for Windows PowerShell as an administrator
    1. Note: Installation instructions and the download for this can be found here: http://technet.microsoft.com/en-us/library/jj151815.aspx
      Windows Azure Active Directory Module for Windows PowerShell
  2. Execute the following command
    1.  Connect-MsolService
      Windows Azure Active Directory Module for Windows PowerShell - Connect-MsolService

      1. Note: Enter in your Office 365 administrator credentials on this step
  3. Execute the following command
    1. Update-MsolFederatedDomain -DomainName mydomain.com -SupportMultiDomain
      Windows Azure Active Directory Module for Windows PowerShell - Connect-msolservice - update-msolfederateddomain

      1. Note: Replace mydomain.com with your federated domain.  If you have multiple domains you are federating with Office 365, add the optional -SupportMultiDomain paramter as well

Office 365 - Change the Alias attribute of an Exchange mailbox for a federated user

Scenario: A federated Office 365 user's Alias is incorrect.  You wish to change it, but changing the proxyAddress or Mail attribute in Active Directory does not update the Alias.

Before this tutorial, you can see the Alias has a typo in it (the m and o are out of place)

Office 365 - User Mailbox - Alias - TypoAfter completing this tutorial, we will update the Alias to look correct

Office 365 - User Mailbox - Alias - Typo Fixed

Solution: Complete the following steps below to update the Alias

  1. Login to one of your Domain Controllers and open up Active Directory Users and Computers
    Server Manager - Active Directory Users and Computers
  2. Find the user that owns the mailbox, right click on them, and select Properties
    Active Directory Users and Computers - User - Properties
  3. Select the Attribute Editor Tab and find the mailNickname attribute
    Active Directory Users and Computers - User - Properties - Attribute Editor - mailNickname

    1. Note: You will need to Enable Advanced Features on Active Directory Users and Computers to see this tab
      Active Directory Users and Computers - View - Advanced Features
  4. Type in the desired value you wish to show up in the Alias field on the Office 365 Exchange Portal and click OK
    Active Directory Users and Computers - User - Properties - Attribute Editor - mailNickname - String Attribute Editor
  5. Click Apply on the Active Directory Users and Computers dialog
    Active Directory Users and Computers - User - Properties - Attribute Editor - mailNickname - Apply
  6. Wait for the Office 365 Directory Synchronization tool runs and updates the users online
    1. Note: Tutorial on how to do this can be found here: http://jackstromberg.com/2012/08/force-directory-synchronization-with-office-365/
  7. Ensure that the Alias field has updated in the Exchange Administrative portal
    Office 365 - User Mailbox - Alias - Typo Fixed

 

Office 365 - Call us overprotective, but we need to verify your account again before opening this document.

Symptom:

When trying to open a document in Office 2013 ProPlus from Office 365's SharePoint environment, you are periodically prompted for credentials to SharePoint Online, OneDrive, and Lync Onlinet (using your email address and password).  Additionally, the affected users are those that have been synchronized from an on-premise Active Directory environment via ADFS.

Side Note: Not sure if this is relevent or not, but we noticed this started to happen after upgrading our ADFS Proxy Servers to Server 2012 R2 (ADFS v3).

You are prompted with the following Sign In box:

Call us overprotective, but we need to verify your account again before opening this document.
Sign In

Once you try signing in, you receive the following error:

We are unable to connect right now. Please check your network and try again later.

Sign In 2

Inside of the Lync 2013 client, you might see the following dialog as well:

Credentials are required

Lync needs your user name and password to connect for retrieving calendar data from Outlook

Sign In 3

Solution:

This error is caused by a variety of different issues.  Please try all of the following below.

If you have a single client having issues

  • Clearing cache of Internet Explorer
  • Running an online repair of Office 365 ProPlus
  • Switching Accounts inside of Outlook (File->Office Account->Switch Account)
  • Deactiving office from Office 365 settings and reactivating

If this is a widespread issue on multiple machines in your environment

  • Verify all proxy servers are functioning
    • If you have multiple proxy servers, ensure your Network Load Balancer is functioning correctly
  • You might be hitting a known bug with the Office 2013 Suite.  See the following KB article on how to try a workaround (this was the fix for an environment I worked on using ADFS and Server 2012): http://support.microsoft.com/kb/2913639

Change Office 365 DirSync Synchronization Frequency/Schedule

By default, you have probably noticed it can take up to 3 hours for a change to be in your on-premise environment to be replicated to your Office 365 environment.  In organizations that have a smaller amount of users, you can change the frequency of the synchronization schedule to replicate the changes to Office 365 more quickly.

  1. Login to the server with the DirSync application (Windows Azure Active Directory Sync)
  2. Open up Notepad as an Administrator
    Notepad - Run as Administrator
  3. Open the folllowing file
    1. C:\Program Files\Windows Azure Active Directory Sync\Microsoft.Online.DirSync.Scheduler.exe.config
      Microsoft_Online_DirSync_Scheduler_exe_config
  4. Change the SyncTimeInterval to how often you want the tool to be run.  The time is in hh:mm:ss
    1. For example, to change a sync frequency to every 15 minutes
      1. Change <add key=”SyncTimeInterval” value=”3:0:0″ /> to <add key=”SyncTimeInterval” value=”0:15:0″ />
        Microsoft_Online_DirSync_Scheduler_exe_config - 15 minutes
  5. Save and Close Notepad
  6. Restart the Windows Azure Active Directory Sync Service
    Windows Azure Active Directory Sync Service - Restart

DirSync - Unable to establish a connection to the authentication service. Contact Technical Support.

Symptom: You receive the following errors when running the Windows Azure Active Directory Sync tool Configuration Wizard or the Microsoft Online Services Directory Synchronization Configuration Wizard.

Synchronization Service Manager shows stopped-server-down status.
stopped-server-down Synchronization Service Manager

You receive the following events inside of event viewer:

Log Name: Application
Source: Directory Synchronization
Date: %Date%
Event ID: 0
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: %ComputerName%
Description:
Unable to establish a connection to the authentication service. Contact Technical Support. GetAuthState() failed with -2147186688 state. HResult:0. Contact Technical Support. (0x80048862)
Log Name: Application
Source: Directory Synchronization
Date: %Date%
Event ID: 102
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: %ComputerName%
Description:
Unable to establish a connection to the authentication service. Contact Technical Support.

Log Name: Application
Source: FIMSynchronizationService
Date: %Date%
Event ID: 6803
Task Category: Management Agent Run Profile
Level: Error
Keywords: Classic
User: N/A
Computer: %ComputerName%
Description:
The management agent "TargetWebService" failed on run profile "Delta Confirming Import" because the server encountered errors.

The Windows Azure Active Directory Sync tool Configuration Wizard presents you the following error message:
Unable to establish a connection to the authentication service. Contact Technical Support.
Unable to establish a connection to the authentication service. Contact Technical Support

Solution: This turns out to be an issue with the provided credentials entered in the Windows Azure Active Directory Credentials step.  Please make sure you verify the following.

  1. Do not use a federated Global Administrator service account.  Federated service accounts are not allowed to be used with the synchronization tool.  You should have a non-federated Global Administrator account with an @mydomain.onmicrosoft.com UPN.
  2. Ensure your Office 365 Global Administrator service account's password has not expired.

Office 365 - The phone number you entered has already been registered by someone else.

Symptom: You receive the following error when trying to enable someone for a Unified Messaging mailbox on Office 365 (Office 365 Admin Portal -> Exchange -> User Account -> Enable Unified Messaging -> Browse for UM mailbox policy).

error
The phone number you entered has already been registered by someone else.
The phone number you entered has already been registered by someone else

Resolution: This was caused by having a duplicate UM Voicemail box number.  You can run the following powershell commands to identify which user has the duplicate number assigned to them.

Set-ExecutionPolicy unrestricted
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $session
Get-Recipient -ResultSize Unlimited | where{$_.emailaddresses -like "*EUM:*PHONENUMBER*"} | fl displayname,emailaddresses

[Tutorial] Upgrading from ADFS 2.0 (Server 2008 R2) to ADFS 3 (Server 2012 R2)

Scenario: You want to upgrade your ADFS 2.0 or 2.1 farm using WID (Windows Internal Database) from Server 2008 R2 to Server 2012 R2.  In this scenario, I have 2 ADFS servers (one as the primary and a second for failover purposes), and 2 ADFS Proxy servers (for load balancing/failover purposes).

NOTE: Prior to writing this article I had only found limited documentation provided by Microsoft on a proper upgrade path for this.  Since then, it apperas that tools had been included with the Server 2012 installation media which will greatly cutdown on the number of steps needed as well as provide as little downtime as possible.  I would highly recommend giving this article a read before proceeding with my article: http://blogs.technet.com/b/askpfeplat/archive/2014/03/31/how-to-build-your-adfs-lab-part4-upgrading-to-server-2012-r2.aspx

My article should still work, but it is definitely not the most efficient way to do an upgrade as pointed out in the technet article above.  My guide essentially goes over cutting over to a completely new ADFS deployment "an upgrade", side-by-side to your production environment. As pointed out below, you cannot add a Server 2012 R2 machine to a Server 2008 R2 ADFS farm as documented in their earlier help articles.

Tutorial

  1. Login to one of your slave ADFS nodes (secondary server) running Server 2008 R2
  2. Remove the node from your load balancer
  3. Stop the AD FS 2.0 Windows Service
  4. Click Start -> Administrative Tools -> Internet Information Services (IIS) Manager Server 2008 R2 - Start - Administrative Tools - Internet Information Services IIS Manager
  5. Select your server and double click on Server Certificates Internet Information Services IIS Manager - Server Home
  6. Right click on your certificate and select Export... Internet Information Services IIS Manager - Export Certificate
  7. Export the certificate to your desktop, type in a password to protect the exported certificate/private key, and select OK
    Export Certificate Properties
  8. Copy the pfx (exported certificate/private key) to your local machine; we will import this on our new server later.
  9. Disjoin the ADFS machine from the domain
  10. Turn the ADFS machine off and retire it
  11. Create a new Server 2012 R2 machine with the same name and IP as your Server 2008 R2 ADFS machine
  12. While the new ADFS machine is being created, login to one of your ADFS proxy servers
  13. Remove the proxy from your load balancer
  14. Stop the AD FS 2.0 Windows Service
  15. Turn the machine off and retire it
  16. Create a new Server 2012 R2 machine with the same name and IP as your Server 2008 R2 ADFS Proxy machine
  17. While the new ADFS proxy machine is being created, login to your new ADFS Server 2012 R2 machine.
  18. Open up Server Manage and select Manage -> Add Roles and Features Server 2012 - Manage - Add Roles and Features
  19. On the Before You Begin screen, click Next > Add Roles and Features Wizard - Before you begin
  20. Select Role-based or feature-based installation and click Next > Add Roles and Features Wizard - Select installation type
  21. Select your server and click Next > Add Roles and Features Wizard - Select destination server
  22. Check Active Directory Federation Services and click Next > Add Roles and Features Wizard - Server Roles - Active Directory Federation Services
  23. Click Next > on Features Add Roles and Features Wizard - Features - Default
  24. Click Next > on AD FS Add Roles and Features Wizard - AD FS
  25. Click Install Add Roles and Features Wizard - Confirmation - Active Directory Federation Services
  26. Click on the Configure the federation service on this server. link once the installation has completed successfully. Add Roles and Features Wizard - Results - Configure the federation service on this server
  27. Check Create the first federation server in a federation server farm on the Welcome screen for the Active Directory Federation Services Configuration Wizard and then click Next > Active Directory Federation Services Configuration Wizard - Welcome
    1. Please see my notes below on why we did not check Create the first federation server in a federation server farm.
  28. Click Next > on the Connect to AD DS step
    Active-Directory-Federation-Services-Configuration-Wizard-Connect-to-AD-DS
  29. Copy the .pfx file we exported from the ADFS server earlier to the new ADFS server
  30. On the Specify Service Properties screen, click on the Import... button Active Directory Federation Services Configuration Wizard - Specify Service Properties - Import
  31. Select your certificate and click Open Select Certificate
  32. Type in the password to the exported certificate and click OK Enter certificate password
  33. Type in a Federation Service Display Name that will be shown to your users when they login to the ADFS service (this can be anything), and click Next > Active Directory Federation Services Configuration Wizard - Specify Service Properties - Federation Service Display Name
  34. On the Specify Service Account screen, click the Select... button Active Directory Federation Services Configuration Wizard - Specify Service Properties - Use an existing domain user account or group Management Service Account
  35. Type in the name of your service account you wish to use for ADFS, click the Check Names button to verify you don't have any typos, and click OK Active Directory Federation Services Configuration Wizard - Specify Service Properties - Select User or Service Account
  36. Type in the password for the ADFS service account and click Next > Active Directory Federation Services Configuration Wizard - Specify Service Properties - Use an existing domain user account or group Management Service Account - Username password
  37. Click Next > on the Specify Configuration Database Active Directory Federation Services Configuration Wizard - Specify Database - Create a database on this server using Windows Internal Database
    1. Note: I choose to continue to use WID, you can switch to SQL if you would like now, however that is outside of the scope of this document.
  38. Click Next > on the Review Options screen Active Directory Federation Services Configuration Wizard - Review Options
  39. Click the Configure button once all the prerequsite checks have passed successfully Active Directory Federation Services Configuration Wizard - Pre-requisite Checks
  40. Click Close once the server has successfully been configured Active Directory Federation Services Configuration Wizard - Results
  41. Open up Internet Explorer on the new ADFS machine and navigate to https://localhost/adfs/ls/IdpInitiatedSignon.aspx to ensure the service is properly running AD FS 3 Test
    1. Note: you should receive an invalid ssl certificate error; that is OK, we will switch the DNS records over once we are ready to transition from our old farm to the new one.
  42. Next, login to your Server 2008 R2 primary ADFS server and recreate the federation trusts on the new Server 2012 R2 primary ADFS server
    1. Start -> Administrative Tools -> AD FS 2.0 Management; select Trust Relationships -> Relying Party Trusts
    2. Recreate all the rules/trusts from your original ADFS server on your new Server 2012 R2 ADFS machine
      1. Note: If you are recreating rules for Office 365, you will need to wait until you switch over our new Server 2012 R2 environment to production.  The reason is when you setup the new ADFS instance, some of the certificates will change causing a certificate mismatch/preventing your users from logging in.  You will need to make sure you follow the following steps when resetting up the Office 365 trust to ensure your users don't receive "Error 80041317": http://support.microsoft.com/kb/2647020/en-us
  43. Login to your new ADFS Proxy server
  44. Import your SSL cerficate from your old ADFS server (from step 8) onto the server's Local Machine certificate store
    1. Right click on Start and select Run
      Server 2012 - Start - Run
    2. Type MMC and click OK
      Server 2012 - Run - mmc
    3. Click File -> Add/Remove Snap-in...
      Server 2012 - mmc - Add Remove Snap-In
    4. Select Certificates and click Add > Add or Remote Snap-ins - Certificates
    5. Select Computer account and click Next > Certificates snap-in - Computer Account
    6. Select Finish Certificates snap-in - Select Computer
    7. Click OK on the Add or Remove Snap-ins screen Add or Remove Snap-ins - Certificates - Local Computer
    8. Expand Certificates (Local Computer), select Personal, and right click, select All Tasks -> Import... Server 2012 - Certificates (Local Computer) - Personal - Import
    9. Click Next on the Certificate Import Wizard Certificate Import Wizard - Welcome
    10. Click the Browse... button Certificate Import Wizard - Browse
    11. Select your certificate and click Open Select Certificate
      1. Note: You may need to click on the dropdown box in the bottom right and select All Files for your pfx file to show up.
    12. Click Next on the File to Import screen Certificate Import Wizard - File to Import
    13. Type in the password to the pfx file, check Mark this key as exportable, and click Next Certificate Import Wizard - Private key protection
    14. Ensure Place all certificates in the following store shows Personal and click Next Certificate Import Wizard - Certificate Store
    15. Click Finish Certificate Import Wizard - Completing the Certificate Import Wizard
    16. Click OK on the Certificate Import Wizard successful dialog boxCertificate Import Wizard - Successful
  45. Edit the hosts file to point your DNS record to your new ADFS server
    1. Open Notepad as an Administrator Server 2012 - Notepad - Administrator
    2. Open the following file: C:\Windows\System32\drivers\etc\hosts Server 2012 - Hosts file
    3. Add in your DNS entry and point to your new ADFS server hosts file - adfs manual entry
    4. Save the file
      1. Note: We will come back to this later and update it to point to our load balancer once we switch over everything.  For now, this lets us test our new deployment while switching things over.
  46. Open up Server Manager
    Server 2012 R2 - Server Manager
  47. Click Manage -> Add Roles and Features
    Server 2012 - Manage - Add Roles and Features
  48. Click Next > on the Before you begin screen Add Roles and Features Wizard - Before you begin
  49. Select Role-based or feature based installation and click Next > Add Roles and Features Wizard - Select installation type
  50. Select your server and click Next > Add Roles and Features Wizard - Select destination server
  51. Check Remote Access on the Server Roles screen Add Roles and Features Wizard - Remote Access
  52. Click Next > on the Features screen Add Roles and Features Wizard - Features - Default
  53. Click Next > on the Remote Access screen
  54. Check Web Application Proxy
  55. ClickAdd Features on the Add Roles and Features Wizard dialog boxAdd Roles and Features Wizard - Web Application Proxy
  56. Click Next > on the Roles Services screen Add Roles and Features Wizard - Role Services - Web Application Proxy
  57. Click Install on the Confirmation screen Add Roles and Features Wizard - Confirmation - Web Application Proxy
  58. Click on the Open the Web Application Proxy Wizard link once the installation succeeds Add Roles and Features Wizard - Confirmation - Web Application Proxy - Open the Web Application Proxy Wizard
  59. Click Next > on the Welcome screen Web Application Proxy Configuration Wizard - Welcome
  60. Type in the FQDN to your ADFS server, the credentials of an account with local admin privileges, and then click Next >Web-Application-Proxy-Configuration-Wizard-Federation-Server
  61. Select your certificate on the AD FS Proxy Certificate screen and click Next >
    Web-Application-Proxy-Configuration-Wizard-AD-FS-Proxy-Certificate
  62. Click Configure on the Confirmation screen Web Application Proxy Configuration Wizard - Confirmation
  63. Click Close once the Web Application Proxy has been successfully configured.Web-Application-Proxy-Configuration-Wizard-Results
  64. After you click close a new window should open.  On the Remote Access Management Console, select Publish
    1. Note: This step only needs to be done once.  It will replicate to all other proxy servers when you set those up at a later time.
      Remote Access Management Console - Publish
  65. Click Next > on the Welcome screen
    Publish New Application Wizard - Welcome
  66. Select Pass-through and click Next >
    Publish New Application Wizard - Preauthentication
  67. Enter in a name, external URL, and internal URL for your federated server (mine were both the same since I use split-dns).  Click Next >
    Publish New Application Wizard - Publishing Settings
  68. Click Close
    Publish New Application Wizard - Results
  69. Add the new Server 2012 R2 ADFS machine to your load balancer and remove your Server 2008 R2 machine.
  70. Add the new Server 2012 R2 ADFS Proxy machine to your load balancer and remove your Server 2008 R2 proxy machine.
  71. Update the hosts file on your Server 2012 R2 proxy machine to point to your load balanced Server 2012 R2 ADFS environment
  72. Retire your Server 2008 R2 ADFS environment
    1. Disjoin the ADFS proxy server from the domain and recycle the machine
    2. Open up PowerShell as an Administrator
      Elevated Powershell
    3. Execute the following commands:
      1. Add-PsSnapin Microsoft.Adfs.Powershell
        Get-AdfsProperties
        get-adfsproperties certificatesharingcontainer
    4. Stop the service on your Server 2008 R2 ADFS machine running the old ADFS farm
    5. Execute the following command to remove the ADFS Farm info from AD (substituting in the information from the Get-AdfsProperties command):
      1. $delme = New-Object System.DirectoryServices.DirectoryEntry("LDAP://CN=484e24a8-5726-4186-8e24-825b77920798,CN=ADFS,CN=Microsoft,CN=Program Data,DC=mydomain,DC=local")
        $delme.DeleteTree()
        PowerShell DeleteTree
    6. Disjoin the ADFS machine from the domain and recycle the machine
  73. Add a new Server 2012 R2 machine and WAP machine to your new ADFS environment for redudnancy (same steps as above, except in Step 27, you will select Add a federation server to federation server farm

Notes: Here is the upgrade compatibility matrix for upgrading ADFS from a specific version to Server 2012: http://technet.microsoft.com/en-us/library/jj647765.aspx

Why did I not check Add a federation server to a federation server farm on the Welcome screen for the Active Directory Federation Services Configuration Wizard?

The reason behind not checking this is I believe Microsoft has a bug in their discovery tool in adding another machine to a farm running ADFS 3.0.  When adding a Server 2012 R2 machine to a farm with only Server 2008 R2 machines running ADFS 2.0, you will receive the following error:

The primary federation server was contacted successfully, but the configuration data was not valid. Ensure that the primary federation server is running Windows Server 2012 R2 or later. Unable to retrieve configuration from the primary server. The primary federation server was contacted successfully, but the configuration data was not valid. Ensure that the primary federation server is running Windows Server 2012 R2 or later. Prerequisites Check Completed One or more prerequisites failed.  Please fix these issues and click "Rerun prerequisites check" The primary federation server was contacted successfully, but the configuration data was not valid. Ensure that the primary federation server is running Windows Server 2012 R2 or later

Symptom: You receive the following error while setting up the WAP (proxy) server:

An error occurred when attempting to establish a trust relationship with the federation service. Error: Not Found An error occurred when attempting to establish a trust relationship with the federation service Error Not Found

Resolution: Make sure you update the DNS records of your ADFS deployment to point to your new ADFS server.  Both the ADFS proxy and ADFS server must be running the same OS version (in this case, Server 2012 R2).