Website under construction

Enabling AD FS for your Exchange organization 
When you are configuring AD FS for claims-based authentication with Outlook Web App and the 
Exchange Admin Center in Exchange 2013, you must turn on AD FS for your Exchange organization. 
You can do this by using the Set-OrganizationConfig cmdlet for your organization. For the example 
environment in this chapter, you would need to do the following: 

Set the AD FS issuer to https://adfs.contoso.com/adfs/ls. 

Set the AD FS URIs to https://mail.contoso.com/owa and https://mail.contoso.com/ecp. 

Find the AD FS token signing certificate thumbprint by using the Windows PowerShell Get-
ADFSCertificate -CertificateType "Token-signing" cmdlet on the AD FS server. Then, assign the 
token-signing certificate thumbprint that you found. 
Using the Exchange Management Shell, type the following code: 
Get-ADFSCertificate -CertificateType "Token-signing" 

---

83 
CHAPTER 2 | Software-defined datacenter 
This will provide you with the token-signing certificate’s thumbprint, on which you run the following 
Set-OrganizationConfig cmdlets: 
$uris = @(" https://mail.contoso.com/owa","https://mail.contoso.com/ecp") 
Set-OrganizationConfig -AdfsIssuer "https://adfs.contoso.com/adfs/ls/" -AdfsAudienceUris $uris
–AdfsSignCertificateThumbprint "1a2b3c4d5e6f7g8h9i10j11k12l13m14n15o16p17q" 
Web Application Proxy troubleshooting 
The sections that follow provide a few tips on how you can troubleshoot issues that might arise in 
environments in which Web Application Proxy has been deployed. 
Collecting information about your environment 
Managing and troubleshooting Web Application Proxy servers requires a good knowledge of 
Windows PowerShell and the cmdlets exposed for Web Application Proxy. When you are 
troubleshooting a Web Application Proxy problem, first take note of any error messages that appear 
in the console. If there aren’t any obvious errors, review the event logs. You can sign in to each server 
and check the event logs, but you can use Windows PowerShell to simplify the process. 
For example, the following Windows PowerShell command will gather all the events that the Web 
Application Proxy server generated in the previous 24 hours, along with their ID, Level, and Message: 
$yesterday = (Get-Date) - (New-TimeSpan -Day 1) ;
Get-WinEvent -FilterHashTable @{LogName='Microsoft-Windows-WebApplicationProxy/Admin'; StartTime=$yesterday} 
| group -Property ID,LevelDisplayName,Message -NoElement |
sort Count, Name -Descending | ft – Name -HideTableHeaders } 
Suppose that you see Event ID 12000 repeatedly on this specific server; however, you have a number 
of Web Application Proxy servers, and you want to see if they are all experiencing the same error. Run 
the following command to collect all the event ID 12000s generated within the previous 10 hours for a 
set of Web Application Proxy servers: 
Foreach ($Server in (gwpc).ConnectedServersName){Get-WinEvent -FilterHashTable @{LogName='Microsoft-Windows-
WebApplicationProxy/Admin'; ID=12000; StartTime=(Get-Date) - (New-TimeSpan -hour 10)} -ComputerName $Server -
ErrorAction SilentlyContinue | group MachineName -NoElement | ft Name -HideTableHeaders }
Now you have the list of all the servers experiencing the issue. For this example, let’s assume that 
there is only one server experiencing this error. 
The TechNet table of error codes can be very useful for resolving the issue 
(
http://technet.microsoft.com/en-us/library/dn770156.aspx
). The table on TechNet suggests checking 
the connectivity with AD FS for this particular Web Application Proxy server. To do so, go to 
https:///FederationMetadata/2007-06/FederationMetadata.xml
and ensure 
that there is a trust relationship between the AD FS server and the Web Application Proxy server. If 
this doesn’t work, run the Install-WebApplicationProxy cmdlet to correct the issue.