In many larger environments, Exchange 2007 may be deployed with multiple Client Access Servers (CAS) across the AD site boundaries. The common configuration is to have users access one CAS server from the Internet and it proxy the request to a different CAS in the AD site where the user’s mailbox is located.
The Internet facing CAS server should have the Internal URL populated with Forms Based Authentication (FBA) and Basic Authentication enabled. The External URL is optional. The authentication method can be any of the 3 configurations allowed, Domain\Username, Username only, or UPN (email address).
NOTE: A stumbling block here is that Integrated Windows Authentication needs to be enabled on the OWA virtual directory. There isn’t a way to enable both FBA and Integrated Windows Authentication from inside the EMC, so IIS Manager must be used.
The second CAS at the remote AD site needs to have FBA disabled with Basic and Integrated Windows Authentication enabled through the EMC. Also the internal URL must be populated with a name the first CAS can resolve through DNS. Ensure that port 443 is clear between both servers. You can test the SSL connectivity by performing a telnet from the first server to the second over port 443.
NOTE: If the external URL is populated on the remote CAS server, OWA will give the user a new URL to try instead of proxying his request. Remember to leave this field blank.
With this configuration, a user accessing OWA from the Internet will get proxied to the best available CAS server in the same AD site his mailbox resides in. Internal Users who access the remote CAS will be automatically authenticated through the Integrated Windows Authentication and then served their mailbox or given the FBA page then proxied to the correct AD site if they access the internet facing CAS.
Http to Https redirection is commonly a preferred configuration for Outlook Web Access for most organizations. The challenges presented in IIS7 are that the built-in redirection feature only allows relative redirection without a full URL entered. To perform Http to Https, the full URL is required. This becomes an issue when organizations are trying to redirect for both internal and external users who commonly are using different URLs to access the server.
The solution is 2 fold.
First, turn on relative redirection by entering the the virtual directory for exchange and checking the “Only redirect requests to content in this directory (not subdirectories)”
NOTE: Http Redirect is a feature in Windows 2008 and must be installed through the Features in Server Manager or through the cmd prompt:
| c:\>servermanagercmd –i Web-Http-Redirect |
NOTE: “Require SSL” needs to be turned off on the Default Web Site. In IIS 7 this will also turn if off on all the virtual directories. Each virtual directory will have to have “Require SSL” turned back on individually.
NOTE: When you apply redirection to the Default Web Site, redirection will also be applied to all subdirectories. It needs to be unchecked on all directories except the Default Web Site.
Secondly, the Http to Https redirection need to be enabled for any URL entered whether its an external FQDN or an internal server name. There is a great article here on Using custom Error 403.4 to perform HTTPS redirects in IIS 7
With the release of Windows 2008 R2, highly available Hyper V deployments have increased in popularity. One of the big questions during these deployments is what to virtualize and what to leave on physical hardware and in particular when it refers to domain controllers.
Domain controllers are basically highly transactional database servers which service most basic network functions including authentication, name resolution, replication, and of course many secondary services like DHCP or Radius.
In my opinion as long as one domain controller is left on local physical hardware or a remote host, the rest can be virtual. The reasoning behind leaving one is the Hyper V host servers running 2008 R2 or 2008 R2 Server Core will belong to the domain. These machines need to function if all the virtual machines are stopped or in a failed state.
As most organizations have more than one domain controller, there should still be a few to virtualize. Lets take a look at the considerations when virtualizing a domain controller.
First the P2V process itself. Since DC’s are highly transactional, it’s necessary to P2V using offline mode. This mode will install an agent and a bootable kernel to the machine, then reboot the machine, much like a password reset disk, and begin the process while all of its transactional processes are stopped. This requires that the hardware be pretty standard so that it’s compatible with the booting kernel especially the network controller. Once the P2V is finished, the agent and kernel will be removed, the host machine will be automatically turned off, and the virtual machine will be started. Please make sure to not bring the physical machine back online while it’s connected to the network since this will give you duplicate domain controllers on the same network.
Second is the VM configuration itself. There are quite a few options when choosing your hardware configuration in a VM. The type of disk controller, emulated or synthetic, dynamic VHD, fixed VHD, or pass-through disk. Pass-through Disk actually allows the VM direct access to a host attached disk and is considered the optimal configuration, however it’s not always a feasible solution depending on the environment. For a virtual disk based domain controller, a virtual SCSI controller is the preferred method. Also a synthetic controller is preferred over emulated, however you will need to have the VM guest additions installed before you’re able to create this controller.
VHD type and placement are also important. Fixed size VHD is extremely more efficient than a dynamic VHD. Since the size of active directory will undoubtedly grow, a fixed size VHD is the way to go. Also the VHD should be placed on it’s own LUN or physical disk and shouldn’t share with another VM or the host operating system. Sharing a LUN between VMs or with the host OS will greatly decrease performance and could have adverse affects on Active Directory. If the VHD is to be placed on IDE physical storage, make sure that write-back caching is disabled.
So virtual domain controllers aren’t necessarily a bad thing, just remember Pass-through Disk > Fixed size VHD > Dynamic VHD.
This week, I had a pretty strange request. An organization wanted to host multiple Email domains in their Exchange environment while keeping it hidden from external mail users and outside parties. Same organization was ok, same AD and Exchange servers were not.
The mail flow portion was pretty simple. Added a new accepted domain to Exchange 2007, to the spam filter appliance, configure LDAP for this new SMTP domain, and change the primary email address for certain users. I used an email policy that assigned the primary SMTP address based an AD attribute. This requires the attribute to be populated during user creation. I also changed the default email policy to not affect these users. Created separate GALs in exchange so there was no crossover between the 2 user bases.
Publishing the OWA URLs however and login process was not quite so easy.
My first step was to get my UC certificate reissued with the new subject alternative names for the new email domain. Since same organization was ok, it was ok for me to use the same certificate with the original SANs listed on it. You have to create a new certificate request on your Exchange 2007 server and resubmit to your CA. Once this is done, import and enable this new certificate on all exchange servers. Then export the certificate and bring it over to the ISA 2006 server.
I created a new OWA publishing rule for my new domain and a redirect rule below it. This however didn’t work straight off. It seems unless the traffic between ISA and your Exchange CAS uses the same FQDN as the common name of the certificate, the CAS will not respond. I got around this by using a different internal name on the second domain rule with the true public FQDN for the first domain name. ie..
First Domain Rule:
 |
Second Domain Rule:
 |
My ISA server has host file resolution that resolves both real FQDNs to the internal IP address of the CAS server. Since I have it configured that Request appear to come from the ISA server computer, the CAS server doesn’t know which rule its responding to and answers to the same URL in both instances. However the users sees the Public URL of either mail.firstdomain.com or mail.seconddomain.com depending on which they used to get there.
This solved ISA and OWA answering to different public URLs. Now I had to change the login process so that users no longer had to type Domain\Username. Email address was the obvious choice as the suffix is different for the 2 domains and wouldn’t appear to have any crossover.
To accomplish this first I had to create 2 new Alternate UPNs in the Active Directory. I added each email domain suffix. I then changed my LDAP authentication login expressions in ISA and remove the domain\* entry and put in both *@firstdomain.com
and *@seconddomain.com
No change was needed on the Exchange CAS as it was already set to Basic Authentication and not Forms Based. This change forced users to login using only their email address (newly created UPN) as their username.
Now the OWA Forms Based Authentication in ISA needed to be changed to ask for email address instead of domain\username. This is accomplished by editing the strings.txt file located at:
C:\Program Files\Microsoft ISA Server\CookieAuthTemplates\Exchange\HTML\nls\en
I replaced the domain\username with email address then restarted the Microsoft Firewall service. The result:
As you can see, no more evidence.
Recently while performing the initial steps for an Exchange 2003 to 2007 migration, I ran into one of the more frustrating issues with Exchange 2003 to 2007 transitions. Broken inter-organization mail flow. After banging my head against the wall for a few hours, and sending enough test emails to get added to who knows how many OBLs, I finally stumbled on the answer.
Exchange 2007 could talk to the 2003 environment as well as route mail outbound to the Internet, however all 03 to 07 mail was getting jammed in the queues. The customer was running Exchange 2003 in an Active-Passive cluster configuration and had problems previously with their Default SMTP Virtual Server. Their resolution was to disable it and create a new SMTP VS Instance as a cluster resource.
When you install Exchange 2007, by default it creates two routing group connectors and binds them to the SMTP VS instance with the index of 1 on the Exchange 2003 side. In this case the disabled Default VS Instance. Luckily this client had a front end 03 server with it’s own Default VS Instance. I was able to restore mail flow by removing the Routing Group Connectors that 07 put in by default using Power Shell, then create new ones that attached to the front end server rather than the mailbox cluster. This also allowed for me to list multiple Hub Transport servers in my connector rather than just the first one installed in the organization. By listing multiple HT servers, redundancy is achieved during the migration period.
To remove the connectors:
How to Remove Routing Group Connectors in Exchange 2007
To create the new ones:
How to Create Routing Group Connectors from Exchange 2007 to Exchange Server 2003
Recently after deploying a highly available Exchange 2007 solution for a customer, I had to test recovery procedures and create a recovery document. Since I was already documenting my steps, I figured I’d share them here as well.
NOTE: This environment consists of a CCR mailbox cluster and a MS NLB cluster with the Hub Transport and Client Access Roles at the production site. The DR site has a server containing the mailbox role and an a server with the Hub Transport and Client Access Roles.
1. First we have to restore the Storage Group to the standby machine
Restore-storagegroupcopy –Identity “ServerName\StorageGroupName”
–StandbyMachine SCRServerName –force
The –Force behind this command is only needed if the production server can no longer be contacted. This will force a restore if the SCR server cannot copy the last log from the source server.
2. Now we have to check the status of our recovery database. It should be in a dirty shutdown state.
eseutil /mh <path to database on SCR> | findstr state
This should give you the state of the database as well as the log prefix for the storage group
3. Now we need to get the database in a clean state so we can mount it
eseutil /R E00 /L <logfile path> /D <database path> /S <system file path>
E00 is the log prefix, yours may differ. Also if you have data loss, you may have to use the /A switch for eseutil.
Repeat step 2 again to check the shutdown state of the database.
4. Move the path of your storage group and database to the restored storage group
Move-StorageGroupPath –Identity “SCRServer\Storage Group Path” –SystemFolderPath
<system folder path> –LogFilePath <Log File Path> –ConfigurationOnly
Move-DatabasePath –Identity “SCRServer\Storage Group\Database Name” –EdbFilePath
<edbfile path> -ConfigurationOnly
5. Set the database to be overwritten in the EMC
6. Mount the Database in the EMC
7. Rehome all User mailboxes to point to the new database on the SCR Server
Get-Mailbox –Database “SCRServer\Storage Group\Database Name” | Where
{$_.ObjectClass –NotMatch ‘(SystemAttendantMailboxExOleDbSystemMailbox)’} |
Move-Mailbox –TargetDatabase “SCRServer\StorageGroup\Database Name”
-ConfigurationOnly
Seems there has been a large enough uproar from the IT community for Microsoft to announce intentions to support Exchange 2007 on the newly released Windows 2008 R2 OS in the near future.
“We always talk about listening to customers and sometimes this is written off by many as 'marketing speak'. In fact, we do take feedback seriously and no input is more important to our engineering processes than your voice.
Earlier this year we made a decision in one direction, and due to the feedback we have received on this blog and elsewhere, we have reconsidered. In the coming calendar year we will issue an update for Exchange 2007 enabling full support of Windows Server 2008 R2. We heard from many customers that this was important for streamlining their operations and reducing administrative challenges, so we have changed course and will add R2 support. We are still working through the specifics and will let you know once we have more to share on the timing of this update.
So, keep the feedback coming. We are listening. “
Kevin Allison
GM Exchange Customer Experience
Source: http://msexchangeteam.com/archive/2009/11/04/453026.aspx
Recently, I had an enterprise customer who was experiencing intermittent and random slow logins across the network by users with Windows XP workstations on a Windows 2003 network. The customer had been fighting this issue for over 2 years and had allocated plenty of different resources towards it throughout that time frame.
Upon first diagnosing the issue, corrupt profiles, corrupt group policy objects, or even network infrastructure all came to mind. The first course of action was to actually find a user who was experiencing the issue with some regularity and to enable verbose logging for the user environment during logon.
To enable verbose logging of the user environment, you have make a registry change.
Insert warning about editing the windows registry and the potential harm it can cause nonsense here
Create a DWORD entry UserEnvDebugLevel at
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon .
Set the value of UserEnvDebugLevel to 0x00000002 (hexidecimal)
For anyone who’s ever looked at a verbose log for the first time and tried to make sense of it, it might as well be written in ancient Sanskrit. Thankfully Microsoft’s Directory Services team has a great post about making sense of a verbose user environment log here: Understanding How to Read a Userenv Log
After reviewing the logs of a few login attempts, I ran across the infamous Failed to Impersonate User 5 error. This is a pretty common userenv error and can be extremely difficult to track down because it has so many causes. Possible causes are
- DNS Issues either with the DNS server itself or on the workstation (The most common culprit)
- Group policy issues with with permissions or file corruption
- Network communication between the workstation and active directory
- Flaky SPN for the computer
- Trust relationship between the computer and the domain
In the next part, I’ll go through the troubleshooting process.