Setting Internal and External URL’s in Exchange 2013
Microsoft made a nice GUI for setting internal and external URL, however they still did not put in the AutodiscoverServiceInternalUri, and the OutlookAnywhere URL in the GUI. In my opinion, if you’re going to make a GUI for setting URL’s, it would make sense to present all the necessary URL settings in the GUI, so certificate errors don’t occur. So I made a nice script for myself to set all the necessary URL’s on a CAS server.
Download the jpg (wordpress hates .txt or .ps1 files) below, and change the extension to .ps1 or .txt after download. Full script text below.
Download the file, change the extension to .ps1, and run it in Exchange shell
#
# Author: Scott Jaworski
# Website: jaworskiblog.com
# Version: 1.0
# Description: This script sets internal and external URL’s on the specified Exchange 2013 Client Access Server
# then displays the results of all the urls that have been set.
# How to Use: Copy the text file to a location on the Exchange server. Change the .txt extension to .ps1,
# Open Exchange Management Shell, Browse to the location of the script in EMS, Run .\Set-Exchange2013Vdirs
#
Function Set-Exchange2013Vdirs
{
$ExServer = Read-Host “Please enter the Exchange 2013 Server Name you’d like to set Vdirs “
$InternalName = Read-Host “Input the internal domain name eg.. IntMail.domain.com “
$ExternalName = Read-Host “Input the external domain name eg. ExtMail.domain.com “
Write-Host “Configuring Directories for $ExServer..” -Foregroundcolor Green
Get-WebservicesVirtualDirectory -Server $ExServer | Set-WebservicesVirtualDirectory -InternalURL https://$InternalName/EWS/Exchange.asmx -ExternalURL https://$externalName/EWS/Exchange.asmx
Get-OwaVirtualDirectory -Server $ExServer | Set-OwaVirtualDirectory -InternalURL https://$InternalName/owa -ExternalURL https://$ExternalName/owa
Get-ecpVirtualDirectory -Server $ExServer | Set-ecpVirtualDirectory -InternalURL https://$InternalName/ecp -ExternalURL https://$ExternalName/ecp
Get-ActiveSyncVirtualDirectory -Server $ExServer | Set-ActiveSyncVirtualDirectory -InternalURL https://$InternalName/Microsoft-Server-ActiveSync -ExternalURL https://$ExternalName/Microsoft-Server-ActiveSync
Get-OABVirtualDirectory -Server $ExServer | Set-OABVirtualDirectory -InternalUrl https://$InternalName/OAB -ExternalURL https://$ExternalName/OAB
Set-ClientAccessServer $ExServer -AutodiscoverServiceInternalUri https://$internalName/Autodiscover/Autodiscover.xml
Set-OutlookAnywhere -Identity “$ExServer\Rpc (Default Web Site)” -InternalHostname $internalName -ExternalHostName $ExternalName -InternalClientAuthenticationMethod ntlm -InternalClientsRequireSsl:$True -ExternalClientAuthenticationMethod Basic -ExternalClientsRequireSsl:$True
Write-Host “Vdirs have been set to the following..” -Foregroundcolor Green
Write-Host “$ExServer EWS”
Get-WebservicesVirtualDirectory -Server $ExServer |Fl internalURL,ExternalURL
Write-Host “$ExServer OWA”
Get-OWAVirtualDirectory -Server $ExServer | Fl internalUrl,ExternalURL
Write-Host “$ExServer ECP”
Get-ECPVirtualDirectory -Server $ExServer | Fl InternalURL,ExternalURL
Write-Host “$ExServer ActiveSync”
Get-ActiveSyncVirtualDirectory -Server $ExServer | Fl InternalURL,ExternalURL
Write-Host “$ExServer OAB”
Get-OABVirtualDirectory -Server $ExServer | Fl InternalURL,ExternalURL
Write-Host “$ExServer Internal Autodiscover URL”
Get-ClientAccessServer $ExServer | Fl AutodiscoverServiceInternalUri
Write-Host “$Exserver Outlook Anywhere Settings”
Get-OutlookAnywhere -Identity “$ExServer\rpc (Default Web Site)” |fl internalhostname,internalclientauthenticationmethod,internalclientsrequiressl,externalhostname,externalclientauthenticationmethod,externalclientsrequiressl
Write-Host “The Powershell URL have not been set as part of this script. Set it if you choose” -ForegroundColor Yellow
}
Set-Exchange2013Vdirs
Giving User Admins Access to Lync Shell
More and more I run into instances where the team that is creating and enabling accounts for Lync is not the same team that is managing the Lync servers. I needed to find an easy way to allow Lync user administrators to access the Lync Shell without logging into the Lync servers. Here is what I came up with.
1.) Open notepad file and enter the following text.
$s = New-PSSession -ConnectionUri https://LyncServer.domain.com/OcsPowershell -Credential (get-credential)
Import-PSSession $s
2.) Save it as LyncShell.ps1
3.) Create a .bat file with the following text.
Powershell.exe -noexit -command “& {C:\FolderPath\LyncShell.ps1}”
Where “C:\Folderpath\LyncShell.ps1″ Is the path where you saved you’re .ps1 on the local desktop.
4.) Give both scripts to your Lync user administrator. Instruct them to run it from a machine that has powershell v2.0 installed. Run the .bat file as an Administrator.
5.) The script will prompt for Lync User Admin Account credentials, and they will be remotely connected to the Lync Shell.
An additional item to note. By default only five remote connections are allowed per user for the remote shell. The connections close after a certain timeout period. The allowed max connections can also be increased. Aaron Tiensivu has a good write up on this. http://blog.tiensivu.com/aaron/archives/1864-Exchange-2010-Beta-The-WS-Management-service-cannot-process-the-request.html
Deciding what cmdlets you want these administrators to be able to run is a discussion for another day, but I’ll give you a hint. RBAC
http://blogs.technet.com/b/csps/archive/2010/06/06/refrbac1.aspx
Happy Administrating
Using DFS for Publishing the Lync File Share
Since the February 2012 update for Lync, the Lync File share can successfully be created on DFS. After configuring this at a customer site, we discovered that some extra rights were required to get it to work. First, I will show you what those settings are, and then I will show you all the errors you will see if it is not set correctly. An easy way to test whether you are experiencing a DFS issue, is to move the Lync File Share to any Windows Server and see if the issue is resolved. You can find instructions for moving the Lync File share here
In DFS, the Everyone Group should have rights to Read and Change. This is what fixed all our issues. What account actually needs those Change rights does not seem to be well documented, if anyone has any ideas please share. The NTFS rights are still locked down, so we didn’t see an issue with opening up the share permissions a bit. This is what our final Share permissions look like in DFS.
This is addition to the normal Share permissions of:
- Share Permissions:
- Domain Administrator: Full Control
- NTFS Permissions:
- Domain Administrator: Full Control
- Everyone: Read & Execute
Onto all the symptoms. This is mostly just to make this solution searchable.
On the Lync Client we saw:
“Type your user name and password to connecto for retrieving response groups.”
Entering the password just made the box re-prompt, but never locked out the account.
On the Lync Server we saw the following error codes:
Error 4096, Error 4101, and Error 21046
Error 4096
An unhandled exception was encountered in WebTicketService service.
Exception Details. System.UnauthorizedAccessException: Access to the path ‘\\domain.com\Applications\LyncPool1\1-WebServices-1\WebAuthStore\WebT_Sign-17FFB89F52E254296C7997D508A7760F196CA.cer’ is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
Error 4101
Failed to save Web Ticket Signing certificate to the file store.
Certificate file path: \\domain.com\Applications\LyncPool1\1-WebServices-1\WebAuthStore\WebT_Sign-1789F52E254296B67997D508A7760F196CA.cer, exception details: System.UnauthorizedAccessException: Access to the path ‘\\domain.com\Applications\LyncPool1\1-WebServices-1\WebAuthStore\WebT_Sign-17FFB89F52E254296CAB679D5A7760F196CA.cer’ is denied.
Error 21046
Address Book Server has encountered an unexpected exception.
Exception: Access to the path ‘\\domain.com\Applications\LyncPool1\1-WebServices-1\ABFiles0000000-0000-0000-0000-0000000000000000000-0000-0000-0000-000000000000′ is denied.
Exception Type: System.UnauthorizedAccessException
Fixing Lync/OWA Integration After Upgrading to Windows 2008 R2 SP1 or .NetFramework 4.0
So you had Lync integration working with OWA brilliantly by followingJeff Guillet’s blog article, and then you patched your Exchange Servers to Server 2008 R2 SP1 and everything broke. Here’s why, and here’s how to fix it.
Cause:
.Net Framework 4.0 is rolled up in Server 2008 R2 Sp1, which is incompatible with the UCMA package required for the Lync/OWA integration. We can see in the Windows Updates that .net Framework 4.0 has been installed. It is possible that this was installed outside of SP1 as an optional update.
Unfortunately we cannot simply Uninstall this update, it does not show up in the list of available updates to Uninstall. So how do we get rid of .Net Framework 4.0 without Uninstalling the Server 2008 R2 SP1 update?
Solution:
1. Download the .Net Framework 4.0 bits from Microsoft, and install it on your Exchange CAS server(s).
2. Once the install is complete, go to Control Panel – Programs and Features, and Remove the .Net Framework 4 Extended, and then the .Net Framework 4 Client Profile.
3. Reboot the Server.
4. Re-run the original .msi and .msp patches you installed for the Lync Integration from Jeff’s blog article. No reboot should be necessary.
5. Open OWA and enjoy your fixed OWA/Lync integration.
Office 365 Hybrid Deployment Options and Impact
This blog post will describe some of the decisions made in the Exchange Deployment Assistant, and how each option would affect user experience as well as the infrastructure that will be required depending on your selection.
The Exchange Deployment Assistant has several options for differing scenarios. On-premises Only, Hybrid, and Cloud Only. In this post I will be diving into the Hybrid Deployment approach.
I will assume we are migrating from a legacy Exchange system like 2003 or 2007, and there will be some period of co-existence where mailboxes will reside on-premises as well as in the Office 365 cloud.
Once you select the Hybrid Deployment and your current e-mail system, you are presented with several options on how you would like your hybrid deployment to behave.
The following diagram illustrates the infrastructure required if we selected ‘No’ for each option. Essentially our base requirements if we are looking to do minimal co-existence, and just have Dirsync populate the cloud users for us.
Let’s start looking at how each option can affect our deployment and end user experience.
1.Do you want all users to use their on-premises credentials when they log on to their cloud-based mailbox?
If we selected ‘No’ for this option, the result would be very close to a Cloud Only solution. Dirsync would be used to sync the on-premises directories, but you would essentially have two separate Exchange organizations, with two e-mail domains, and no password syncing.
Now let’s see what changes when we select Yes for this option.
As you can see,an ADFS and ADFS proxy server are added to the deployment, and the remote user authentication traffic has changed. The Office 365 mailbox user will now login with their local AD credentials to gain access to their Office 365 mailbox. Alternatively you could forgo the ADFS proxy server if users use a VPN for remote access to the network.
2. Do you want both on-premises and cloud-based users to use the same domain for their e-mail addresses?
Let’s see how each selection would change our deployment.
I can’t think of a good reason any company would want to select no for this option, but there it is.
3. Do you want mail sent to the internet from the cloud-based organization to go through the Hybrid Server first?
Some organizations may have on-premises archiving or journalism solutions that need to be maintained. It is possible to have all mail inbound and outbound still route through an on-premises server if desired. Note that the on-premises infrastructure is a single point of failure for mail flow in this scenario.
4. Do you want both on-premises and cloud-based users to share calendar free/busy information?
This, in my opinion, is the backbone of the Hybrid Deployment. Selecting ‘Yes’ to this option allows for some additional functionality including (from technet):
- Free/busy sharing The free/busy sharing feature enables calendar information to be shared between on-premises and cloud-based organization users. Free/busy sharing is enabled as part of the federated delegation and organization relationship configuration for the on-premises and cloud-based Exchange organizations. Learn more at Understanding Federated Delegation.
- Mailbox moves The mailbox move feature enables on-premises mailboxes to be moved to the cloud organization while preserving user’s Microsoft Office Outlook profiles and offline .ost folders. Mailbox move also enables moving cloud mailboxes to the on-premises organization.
- Message tracking The message tracking feature records the SMTP transport activity of all messages transferred to and from the hybrid Hub Transport servers between the on-premises and cloud-based organizations. You can use message tracking logs for message forensics, mail flow analysis, reporting, and troubleshooting. Learn more at Understanding Message Tracking.
- MailTips MailTips are informative messages displayed to users while they’re composing a message. By enabling MailTips in the hybrid deployment, on-premises and cloud-based senders can adjust messages they’re composing to avoid undesirable situations or non-delivery reports (NDRs) between the organizations. Learn more at Understanding MailTips.
- Online archiving Online archiving enables the cloud-based organization to host user e-mail archives for both on-premises and cloud-based users. Learn more at Configure Exchange Online Archiving.
- Outlook Web App redirection Outlook Web App redirection provides a single, common URL to access both on-premises and cloud-based Exchange mailboxes. The hybrid server automatically redirects Outlook Web App requests to the on-premises mailbox server or provides a link to users for their mailbox in the cloud-based organization. Learn more at:
- Secure mail Secure mail enables secure message delivery between the on-premises and cloud organization via Transport Layer Security (TLS) protocol. The on-premises and cloud organizations are mutually authenticated through digital certificate subjects and e-mail headers and rich-text message formatting are preserved across the organizations.
Without the federated trust between the organizations, user experience will differ between cloud-based users and on-premises users. In most cases, we want to make the end-user experience as seamless as possible.
5. Do you want users to use a single URL to access their mail regardless of where the mailbox is located?
If No is selected for this option, migrated users will have to be instructed to use the Office 365 URL for OWA login.
If Yes is selected, the same URL can be used wherever the mailbox resides, however the redirect is manual, and an Office 365 user will have to authenticate again.
In this post I discussed how each deployment option from the Exchange Deployment Assistant will affect your deployment scenario. There are many other decisions to make outside of the deployment assistant, like high availability and security that are out of scope for this blog post. I hope this has cleared up some questions around the options available for an Office 365 Hybrid Deployment.
Alternative Client Access Cutover Approaches for Exchange 2010
When migrating from Exchange 2003 or 2007 to 2010, there is always a discussion about how coexistence works for external users. The Exchange Team Blog has an amazing post on how Microsoft would like you to do this. You can find it here. The Exchange Team’s approach is to force all users to connect to the new Exchange 2010 Client Access Server in one fell swoop. What the Exchange Team Blog article does not cover are the alternatives to doing a Big Bang cut-over of the Client Access Role.
There are a few risks that I see associated with the Big Bang cut-over approach.
1. There is only one -Exchange2003URL attribute that can be configured. If end-users are using webmail.domain.com externally, and webmail.domain.local internally, this creates a problem. If you have heavy internal OWA users, you may have to re-architect your internal DNS or routing traffic to get both internal OWA users and external OWA users to be able to resolve the lone Exchange 2003/legacy URL. For some companies, this creates a large hurdle for Exchange co-existence, and impacts the timeline for deployment.
2. All Active-Sync devices start using the Exchange 2010 CAS server at the cutover point. This creates an issue, because many active-sync devices behave differently or simply will not work on Exchange 2010. This may result in a flood of help desk calls and angry users at the time of the cut-over. Many times if the device does not work with Exchange 2010, the user will be forced to download a payed app.
So there is some risk associated with OWA and ActiveSync co-existence. In my experience, Outlook Anywhere doesn’t experience issues unless the public address for Outlook Anywhere is different than the certificate common name.
So what are the alternatives?
One alternative that an overwhelming number of companies go for, is to change the webmail address. If it was webmail.domain.com before, moving forward with Exchange 2010 the webmail address could be mail.domain.com. As user’s mailboxes are migrated over, they are instructed to start using the new address. The user will also have to change the Exchange Server Address on their phone. This may result in some frustration to users, but since you can migrate as many or as few users over as you’d like each night, the migration can essentially be throttled to match the user support load. It would look something like this.
Another, better alternative is to use your reverse Proxy, like Forefront Threat Management Gateway or ISA 2006 to direct user traffic based on an Active Directory Group Membership. This method has the best of both worlds because the users can continue to use the same webmail address, and all users do not have to be cutover at the same time. There is some overhead associated with this method for the Administrator. As user mailboxes are migrated, the user accounts will have to be put in an Active Directory Security Group that the reverse proxy will use to direct the user’s traffic to the new Exchange 2010 CAS Server. This method looks something like this.
This is my preferred method when a reverse proxy is in place. The webmail address does not have to be changed, and any active-sync devices issues that may occur will not affect the entire company at once. Microsoft might come back and say that any Active-sync devices that you are supporting, should be tested with the new server anyway. In my experience, this is rarely realistic.
In this post, I described some alternative methods to the “Big Bang” approach to cutting over the Client Access Role. As we can see, using Forefront Threat Management Gateway we can continue to keep the old webmail address, but not have to cut all users over at the same time.
Do any of you have experience with one or all of these methods? Which approach do you prefer?
Logging All Powershell Commands and Output
There have been a number of occasions where I have accidentally closed out of powershell, and had to retype a script that took some time to create, or wanted to go back to see what commands I had already run. Usually the up Arrow Key is sufficient for this, however what about commands that you ran a few days ago?
This post will walk you through setting up a powershell profile to automatically log all activity within powershell.
1. Create the Folder Path for the script output file. Mine is C:\PowershellLog
2. We need to allow the custom profile to be able to execute. This will allow Powershell to execute .ps1 scripts written by you, but will still prompt for unsigned scripts from the internet. To allow powershell to execute custom ps1 scripts, open Powershell and run the following command.
Set-ExecutionPolicy RemoteSigned
3. Next create a Powershell profile that will be loaded every time powershell is opened. Type the exact command below.
New-item -type file -path $profile -force
4. The profile can now be edited to execute custom commands at startup. This can include loading custom aliases, setting the powershell window colors, heading etc.. Today I will just be using it to setup a transcript for Powershell. To edit the profile in Notepad, type the following in Powershell.
notepad $profile
5. This will open your profile in notepad. We can now set the default location, add a time stamp as well as a transcript file to the profile. Now every time powershell is opened, it will log the date and time, as well as append all commands and outputs to a text file. This is what the entirety of my profile looks like.
Set-Location C:\
start-transcript C:\PowershellLog\PSTranscript.txt -append -noclobber
$a = Get-Date
“Date: ” + $a.ToShortDateString()
“Time: ” + $a.ToShortTimeString()
6. Save the notepad file. Now if I browse to C:\PowershellLog\PSTranscript.txt, I will see the following logged for every new powershell session I open, as well as my complete history of everything that has ever been run in powershell, as well as the associated outputs that were displayed in powershell.
Transcript started, output file is C:\PSTranscirpts.txt
Date: 8/5/2011
Time: 1:42 PM
PS C:\>
This will also work for Exchange Management Shell, or any other pre-baked Powershell application. Pretty cool huh? Note that this only applies to the current user. I may address doing this for multiple users at a later date. Let me know if that is something you would be interested in seeing.
