RSS Subscription 168 Posts and 2,769 Comments

Archive for November, 2008

Update Rollup 5 for Exchange Server 2007 SP1 (KB953467)

I don’t normally post about updates as my blog is more article focused than update focused.  I did however feel the need to post about this update as this is a pretty significant update with a ton of fixes.  The three biggest updates I believe are the UM diversion header fix and the OAB fix on Server 2008 clusters (both SCC and CCR).

For more detailed information about those three fixes, check the following:

  • KB949968 Unified Messaging does not handle the diversion header correctly in Exchange Server 2007 Service Pack 1
  • KB954197 Exchange 2007 CAS cannot copy the OAB from the OAB share on Windows Server 2008-based Exchange 2007 CCR clusters
  • KB957978 The OAB generation is unsuccessful and Event IDs 9328 and 9373 are logged in the Application log in a Windows Server 2008-based Exchange 2007 Single-Copy cluster environment

You can obtain more information about this Rollup here and you can download here.  I have also updated my blog post which contains existing/resolved issues with Exchange 2007 SP1 on Server 2008 as well as general information I felt important to share.  You can check out that article here.

This is a cumulative update rollup and replaces the following:

  • KB945684 Description of Update Rollup 1 for Exchange Server 2007 Service Pack 1
  • KB948016 Description of Update Rollup 2 for Exchange Server 2007 Service Pack 1
  • KB949870 Description of Update Rollup 3 for Exchange Server 2007 Service Pack 1
  • KB952580 Description of Update Rollup 4 for Exchange Server 2007 Service Pack 1

Share

Contest: Giving away two free copies of OCS 2007 Standard (two winners)!

I have two retail copies of Office Communications Server 2007 Standard Edition that I don’t need.  These are copies that I have obtained from events and are not-for-resale copies.  But hey, what better way to get rid of them than to give them away in a contest!

If you are not familiar with OCS 2007, it is a fantastic Microsoft product that provides Instant Messaging, Web Conferencing, Audio Conferencing, Video Conferencing, and PBX-type functionality (Enterprise Voice) where your Communicator Client can make phone calls to the PSTN as well as other Communicator users in your environment.  I encourage you to learn more about OCS 2007 here. As always, feel free to drop me an e-mail if you have a question.

There will be two winners and each winner will receive one copy.  Two winners will be chosen at random.

Contest Guidelines:

The details are very simple (one entry per person):

  1. Sign up and enter a valid e-mail address in your profile as this is how I will contact the winners
  2. Make a comment in this blog post about what you like best about Microsoft’s Unified Communications offerings

Timeline

The contest will end December 6th (GMT -06:00) Central Time (US & Canada) at midnight (so the night of the 5th).  Any submission after this time will not count.  After the deadline, I will choose the two winners at random and contact you via the e-mail address you have set.  If you have any issues and/or questions, contact me by e-mail using the e-mail link at the top right of my blog homepage.

The contest has ended and the winners have been e-mailed!

Share

Autodiscover, DNS, Certificates, and what you need to know

The Autodiscover service, Certificates, DNS, etc. are a very tricky subject which depends a lot on your environment. I will provide general information while also providing real world guidance.  The method I describe below (using autodiscover.domain.com) is not the only method but it is the recommended method by Microsoft and the most widely used. If you have specific questions that relate to your environment or are confused, please comment and I will help you out.

The topics I will cover include:

  • DNS – Split DNS or no Split DNS
  • Internal Autodiscover and the Service Connection Point
  • External Autodiscover Access
  • Web Service InternalURLs and ExternalURLs
  • Real World Example of InternalURLs and ExternalURLs
  • Proxying and Redirection
  • Requesting our Certificate

There is the topic of Autodiscover Site Affinity as well.  In this article, I will not be talking about how to configure Autodiscover Site Affinity as I have blogged about this in the past in great detail.  You can read this article here.  I will briefly touch on the purpose of Autodiscover Site Affinity and why you may want to use it throughout the article.

DNS – Split DNS or no Split DNS

For those that do not know what Split DNS is, it’s when you have an internal DNS zone that matches your external (internet) DNS.  For example, shudnow.net is my external DNS.  If my domain was shudnow.local, I wouldn’t have Split DNS due to the difference in DNS Namespaces.  But if I add a primary DNS zone on my Domain Controllers for shudnow.net so the zone is available internally, I would then have Split DNS.  Or having your AD Domain match your external DNS is also considered Split DNS.

When you configure your Autodiscover service, there is something called InternalURL, ExternalURL, and AutodiscoverServiceInternalURI.  These will all have to be configured appropriately depending on your DNS configuration.  For example, if you don’t have Split DNS, your InternalURL would have to point to shudnow.local and your ExternalURL would have to point to shudnow.net.  If you do have Split DNS, your InternalURL can point to shudnow.net and your ExternalURL woudl also point to shudnow.net.

As you can see, the namespace that is specified when configuring the Autodiscover service depends on your DNS setup both internally and externally.

Internal Autodiscover and the Service Connection Point

The Autodiscover service is a mechanism that can do several things.

  • Automatic Mailbox Creation
  • Redirects Outlook 2007 clients to point to the correct server in which their mailbox is located
  • Provides URLs to Web Services for Outlook 2007

When you first launch your Outlook 2007 client (Outlook 2007 required for Autodiscover access), it will search Active Directory for a Service Connection Point (SCP) record.  Every time a CAS Server is installed, it will register this SCP record within Active Directory in the following location:

CN=Autodiscover,CN=Protocols,CN=<CASServer>,CN=Servers,CN=Exchange Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services

When an Outlook 2007 client has the ability to find this record because they are domain joined and on the internal network, they will locate all SCP records and choose one at random.  If you have slow links or want to remove this randomness, Autodiscover Site Affinity can be used.  This SCP will return the AutodiscoverInternalURI FQDN in which this client should contact the Autodiscover service.  You can modify this FQDN by using the following command:

Set-ClientAccessServer -Identity CASServer -AutoDiscoverServiceInternalUri https://LocationOfCAS/Autodiscover/Autodiscover.xml

By default, the SCP is configured with the following URL (Uses NetBIOS instead of FQDN):

https://CASServer/Autodiscover/Autodiscover.xml

Now in the above Set-ClientAccessServer cmdlet, I specified the location as LocationOfCAS because the FQDN is largely dependent on a couple things.  You can set it to the NetBIOS as long as the certificate you request contains the NetBIOS name of the CAS.  You can set it to the FQDN of the server as long as the certificate you request contains the fQDN of the server.  You can set it to any FQDN really including your OWA URL (owa.shudnow.net perhaps) as long as that name is on the certificate.

You can use the NetBIOS name in the certificate, but you will be exposing your NetBIOS name to internet users.  Some may think this is a big deal while others don’t care too much.  Personally, and this is just a personal opinion, is who cares.  It’s not like an attacker is going to access your server by the NetBIOS name over the internet.  And if a hacker did get into your network, it’s not because you exposed the NetBIOS name.

Now if you were using ISA and internal PKI, you have the option of utilizing an internal certificate on Exchange 2007 and using a public certificate on ISA and have clients on the internet utilize the ISA certificate in which ISA will proxy the data using the internal certificate.  In this scenario, you can use NetBIOS names on your internal certificate and only the publicly accessible names on the ISA certificate.  Or if you don’t care about exposing the name of the server, you can use the same certificate on Exchange and ISA.  You would need to check with your certificate vendor if this is allowed as it may not be or you may have to pay an additional fee to utilize the same certificate on more than one server.

So an example of how this works for domain joined clients who have access to Active Directory is included on the Autodiscover Whitepaper:

A domain joined Outlook 2007 client will find this SCP record which will return the AutodiscoverInternalServiceURI you specify with Set-ClientAccessServer.  Again, don’t forget that it’ll get a list of all SCPs for all CAS servers in your environment and use one at random.  If you have slow links or just want to force Outlook clients to use a CAS in their own site, check out my article here.

External Autodiscover Access

So we now understand how we access the Autodiscover service when we are domain joined and internal to the network.  What happens if we are on the corporate network and are not domain joined or we are external to the network and doin’t have AD connectivity?  Or what happens if we connect via Outlook Anywhere when internal or external to the network? Essentially, what happens when we don’t have access to Active Directory?

Because our Outlook 2007 clients don’t have access to Active Directory, we cannot obtain the AutodiscoverServiceinternalURI since the client can’t get to the SCP record.  Because of this, Outlook 2007 will fall back to utilizing a different method.  The first method is to contact the following DNS records in order (domain = the user’s primary SMTP domain):

  • https://shudnow.net/autodiscover/autodiscover.xml
  • https://autodiscover.shudnow.net/autodiscover/autodiscover.xml

The majority of people will use the autodiscover.shudnow.net method.  Taking a close look at the URLs, we will utilize https.  This means that we will need the autodiscover.shudnow.net name in our certificate.  To have multiple names in our certificate, we will need a Unified Communications Certificate that is provided by various vendors.  My favorite certificate vendors are Entrust followed by Digicert.

So let’s say we want our NetBIOS name on our certificate, FQDN of CAS, our OWA FQDN, and our Autodiscover name, we’d have the following FQDNs on our certificate.

  • OWA.shudnow.net
  • CASServer
  • CASServer.shudnow.net
  • autodiscover.shudnow.net

But again, as stated earlier, if you have ISA, you have the capability of using an internal certificate from your own PKI infrastructure and then using a 3rd party certificate on ISA and have external client access to ISA using the 3rd party certificate in which ISA will proxy that traffic to the CAS using the internal PKI certificate.  This allows you to hide your internal server names if you wish.  Otherwise you can just use your third party certificate across the board (costs may increase depending on licensing for the certificate).

So an example of how this works for domain joined clients who don’t have access to Active Directory, Outlook Anywhere clients, or non-domain joined clients is included on the Autodiscover Whitepaper:

As you can see, Outlook 2007 attempts to connect to Active Directory to get a list of all the SCPs and it fails.  Because of this, Outlook 2007 then attempts to contact autodiscover.shudnow.net.  There would need to be an A record for autodiscover which will lead the client to a CAS server.

Web Service InternalURLs and ExternalURLs

General Information (Outlook 2003 Vs Outlook 2007)

As has been stated earlier in the article, one of the functions of the Autodiscover Service is to provide Web Service URLs to Outlook 2007 clients.  It does this by providing either InternalURLs or ExternalURLs to clients depending on how they are connecting.

To first understand why we have InternalURLs and ExternalURLs for Exchange 2007 Web Services, we must understand a little bit about Outlook 2003 and Outlook 2007 and how they differentiate from how they access these services.  Outlook 2000 works the same way as Outlook 2003 but Outlook 2000 is not supported for Exchange 2007.

Microsoft is trying to de-emphasize public folders.  De-emphasize as in they’re not adding new features for public folders and they’re adding other applications to take over the functionality of public folders.  An example is SharePoint with its shared contacts, discussion lists, etc…  Microsoft provides a good article on Public Folders Vs SharePoint and their support for public folders in the future in addition to a feature matrix.  You can find this article here.

Because of this, Outlook 2007 was given the functionality to obtain features that were previously in public folders through IIS.  For example, the OAB is a system folder within your public folders.  Your CAS will use the file distribution service to copy the OAB files from the OAB Generation server to any CAS that is allowed for web distribution.  This allows the OAB files to be distributed by the CAS.  This allows Outlook 2007 to bypass needing public folders for OAB.

So because of this, Outlook 2007 doesn’t require any public folders to retrieve things like Free Busy, OAB, etc…  Outlook 2003 doesn’t have the built in functionality to retrieve this data that way and must have public folders for things like OAB and Free/Busy.

InternalURLs

The Autodiscover service has an Outlook Provider called EXCH.  This provides access to Outlook 2007 clients who are able to access the Autodiscover service using the SCP record in Active Directory.  When an Outlook 2007 client access this SCP record and utilizes the AutodiscoverInternalURI record to access the Autodiscover Service, they access the EXCH Outlook Provider on that CAS Server’s Autodiscover Service.  The Autodiscover Service will then fetch InternalURL records to feed back to the client in an Autodiscover.xml file.

ExternalURLs

The Autodiscover service has an Outlook Provider called EXPR.  This provides access to Outlook 2007 clients who are NOT able to access the Autodiscover service using the SCP record in Active Directory.  When an Outlook 2007 client cannot access this SCP record and  utilizes the Autodiscover.PrimarySMTPDomain.TLD record to access the Autodiscover Service, they access the EXPR Outlook Provider on that CAS Server’s Autodiscover Service.  The Autodiscover Service will then fetch ExternalURL records to feed back to the client in an Autodiscover.xml file.

Configuring InternalURLs and ExternalURLs

There are several Web Services that the Autodiscover Service will return to an Outlook 2007 client.  These consist of:

  • Web Services (Includes Out of Office, Availability Service for Free/Busy, etc.)
  • Offline Address Book
  • Outlook Anywhere
  • Exchange ActiveSync
  • Unified Messaging

In order to configure these services, you would run the following commands:

Note: The FQDNs depend on the environment, Split DNS vs no Split DNS, what names will go on the certificate, etc.)  This is what I will cover in Part 2 using real world examples.  The commands provided below are just examples on the syntax.

Set-WebServicesVirtualDirectory -Identity “CASServer\EWS (Default Web Site)” -InternalURL https://Host.InternalDNSNamespace.TLD/EWS/Exchange.asmx -ExternalURL https://Host.ExternalDNSNamespace.TLD/EWS/Exchange.asmx -BasicAuthentication:$true

Set-OABVirtualDirectory -Identity “CASServer\OAB (Default Web Site)” -InternalURL https://Host.InternalDNSNamespace.TLD/OAB -ExternalURL Host.ExternalDNSNamespace.TLD/OAB -RequireSSL:$true

Note: When configuring the URLs for the OAB Virtual Directory, a good thing to make note of is that Outlook uses BITS to connect and download the OAB.  BITS does not support self-signed certificates.  This is why the OABVirtualDirectory is the only Service to use http instead of https by default.  If you use https, you will need to use a trusted pki certificate instead of a self-signed certificate for IIS.

Enable-OutlookAnywhere -Server CASServer -ExternalHostname “Host.ExternalDNSNamespace.TLD” -ClientAuthenticationMethod “Basic” -SSLOffloading:$False

Note: The above Enable-OutlookAnywhere command works on SP1. For RTM, substitute -ClientAuthenticationMethod with -ExternalAuthenticationMethod.

Set-ActiveSyncVirtualDirectory -Identity “CASServer\Microsoft-Server-ActiveSync (Default Web Site)” -ExternalURL https://Host.ExternalDNSNamespace.TLD/Microsoft-Server-Activesync

Set-UMVirtualDirectory -Identity “CASServer\UnifiedMessaging (Default Web Site)” -InternalURL https://Host.InternalDNSNamespace.TLD/UnifiedMessaging/Service.asmx -ExternalURL https://Host.ExternalDNSNamespace.TLD/UnifiedMessaging/Service.asmx -BasicAuthentication:$true

Real World Example of InternalURLs and ExternalURLs

So let’s go through a real  world example using my domain as an example.  I will then explain what we can tweak if we had ISA or have Split DNS.

Example

Environment:

  • Shudnow.local AD Domain
  • Shudnow.net External DNS
  • No Split DNS
  • No ISA

Certificate Requirements:

  • Do not contain NetBIOS or Server FQDN on Certificate
  • Provide OWA/Outlook Anywhere/EAS/Web Services Connectivity over webmail.shudnow.net
  • Grant Autodiscover Access from the outside
  • Provide Web Service connectivity over webmail.shudnow.local for internal uses

Results:

  • InternalURL namespace will be Shudnow.local
  • ExternalURL namespace will be Shudnow.net
  • Include webmail.shudnow.net on certificate for external OWA, Outlook Anywhere, EAS, and Web Services (OAB/OOF/EWS)
  • Include webmail.shudnow.local on certificate for internal Web Services
  • Include autodiscover.shudnow.net on certificate

Commands:

  • Set-ClientAccessServer -Identity CASServer -AutoDiscoverServiceInternalUri https://webmail.shudnow.localS/Autodiscover/Autodiscover.xml
  • Set-WebServicesVirtualDirectory -Identity “CASServer\EWS (Default Web Site)” -InternalURL https://webmail.shudnow.local/EWS/Exchange.asmx -ExternalURL https://webmail.shudnow.net/EWS/Exchange.asmx -BasicAuthentication:$true
  • Set-OABVirtualDirectory -Identity “CASServer\OAB (Default Web Site)” -InternalURL https://webmail.shudnow.local/OAB -ExternalURL webmail.shudnow.net/OAB -RequireSSL:$true
  • Enable-OutlookAnywhere -Server CASServer -ExternalHostname “webmail.shudnow.net” -ClientAuthenticationMethod “Basic” -SSLOffloading:$False
  • Set-ActiveSyncVirtualDirectory -Identity “CASServer\Microsoft-Server-ActiveSync (Default Web Site)” -ExternalURL https://webmail.shudnow.net/Microsoft-Server-Activesync
  • Set-UMVirtualDirectory -Identity “CASServer\UnifiedMessaging (Default Web Site)” -InternalURL https://webmail.shudnow.local/UnifiedMessaging/Service.asmx -ExternalURL https://webmail.shudnow.net/UnifiedMessaging/Service.asmx -BasicAuthentication:$true

Note: Don’t forget that for the Enable-Outlook Anywhere cmdlet, you should substitute -ClientAuthenticationMethod with -ExternalAuthenticationMethod if you are using Exchange 2007 RTM.

So as you can see, our InternalURL is different from ExternalURL.  What would have changed if we had Split DNS?  Well, I could have just used webmail.shudnow.net across the board and not needed to use webmail.shudnow.local and not need it in the certificate.  If we put the NetBIOS name of our CAS on our certificate, we really wouldn’t have to change any of our InternalURLs because as I stated earlier, the InternalURL defaults to using the NetBIOS name in the URL by default.

Now what if we were adding ISA?  Well, we could have done the same thing with our URLs in our example and/or if we were adding ISA.  What is different is what I explained above, if you get an Entrust certificate for instance, you can use that certificate on Exchange, export it with its private key, and also use that certificate on ISA (contact Entrust to ensure this is alright with your environment).  Or you can use your own internal PKI, include NetBIOS names on your certificate, and use NetBIOS names instead for your InternalURLs and just have ISA accept communications on an Entrust certificate and then just proxy using your InternalPKI.

In regards to ISA, I have utilized several methods before:

  • I have not used the NetBIOS name on the certificate or the CASServer FQDN on the certificate.  I included only the webmail.domain.com and autodiscover.domain.com in the certificate, used that same certificate on both Exchange and ISA.  The client was of course using Split DNS.
  • I have also put the NetBIOS name on the certificate and the CASServer FQDN on the certificate.  I then did the same method as above.  I exported the certificate with its private key, put it on ISA, and used that for remote access.  Isle released a video in which she goes through the entire process of using this method as well as publishing it via ISA here.
  • I have also used an Internal PKI and put the NetBIOS names on the certificate that lives on the CAS Server and then use a separate certificate from a thrid party certificate vendor and used that exclusively on ISA.  ISA receives traffic, decrypts the traffic for application layer inspection, and then reencrypts it using the Internal certificate’s public key.  Remember, encryption uses the receiving party’s public key.  You’ll want to make sure you have the internal PKI’s root cerrtificate installed on ISA.

As you can see, a lot of it depends on your environment, what you have set up, if you have ISA in the mix, etc… It’s very difficult to cover all the scenarios out there.  But as I said in the beginning of this article, if you have a question, feel free to comment and I’ll help you out.

Proxying and Redirection

It is important to understand how CAS to CAS communication works if you are in a multi-site configuration.  Your certificates for CAS to CAS communication are important.  When you are dealing with CAS Servers, there are two kinds: Intra-facing CAS Servers and Internet-facing CAS Servers.

An internet-facing CAS Server is one that accepts communication from the internet.  Because of this, it will have both ExternalURLs and InternalURLs defined.  An intranet-facing CAS servers will have only InternalURLs defined.

The way proxying works is as follows:

  1. A request for webmail.shudnow.net/owa comes in to an Internet-facing CAS which belongs in SiteA.
  2. The Internet-facing CAS checks what mailbox the user belongs to and sees the mailbox is located in SiteB.
  3. The Internet-facing CAS checks to see whether there is a CAS in SiteB.
  4. The Internet-facing CAS finds a CAS in SiteB and checks its list for ExternalURLs and InternalURLs.  If an ExternalURL is defined, the CAS in SiteA will redirect the client’s browser to the ExternalURL of the CAS in SiteB.  If no ExternalURL is defined, the CAS will proxy the OWA traffic in the background using the InternalURL.

One thing to keep in mind is that Redirection is only possible for OWA traffic.  All other services can only utilize the InternalURL and proxy.

Now here is where certificates are important.  If you’re doing 100% proxying, it’s fine to use the self-signed certificate as long as the CAS can communicate with the other CAS servers over its NetBIOS name (*cough* WINS *cough*) or using its FQDN which is a SAN name on the self-sigend certificate.  If you don’t want WINS, you need to ensure that all InternalURLs utilize the FQDN name of the CAS or request a new certificate with whatever you like and set the InternalURL to use that FQDN.

If you do decide you want to do OWA redirection and let the other services proxy, you’ll want a public certificate on the CAS in SiteB to support Redirection.  And if you’re not using Split DNS, make sure you include 2 names on the certificate, one that will allow Redirection using your external namespace and one that’ll support web services over your internal namespace.

If you are interested in learning more about CAS to CAS and/or CAS to Mailbox/BackEnd communicatiosn for proxying/redirection, check out the following articles from Microsoft:

Requesting our Certificate

So now we have all the information we need to determine what we want on our certificate.  How can we actually obtain the certificate?  It is done through the Exchange Management Shell.  Digicert has provided a tool which can help you create your certificate request.  You can find this tool here.

So taking a look at our example above, we determined we’d use the following names on the certificate:

  • webmail.shudnow.net
  • webmail.shudnow.local
  • autodiscover.shudnow.net

Once you enter your command into the Exchange Management Shell, it will place a .csr file in C:\.  This file will contain text that provides you with the  text information you need to submit to your certificate vendor. Once they approve the certificate, they will provide you with  some text information which you then store in a .cer file.

Once you have this .cer file, you can import it.  It will then bind to your previous certificate request.  You can import it by running the following command and enable services on the certificate all in the same one liner:

Import-exchangecertificate –path <full path to cert file> | Enable-exchangecertificate -services IMAP, POP, UM, IIS, SMTP

Note: The services you enable depend on what services are enabled on the server you are running this command.

Then to be safe, run the following command:

iisreset -noforce

Tip: When you use your New-ExchangeCertificate command, you can leave the autodiscover.domain.com name out of your certificate request and use the following switch: -IncludeAutodiscover and -IncludeAcceptedDomains.  This command will take a look at your environment and add the names as it sees fit. If you have a lot of Accepted Domains, this may not be feasable.  But the functionality is there if needed and requires SP1.

Share

RDP over SSH using port 443

I recently built my own home lab which lives on Hyper-V managed by System Center Virtual Machine Manager 2008 thanks to my Technet Subscription. I wanted to be able to manage this lab when I am at client sites in case I ever need to test something.  Port 3389 is often scanned by hackers but Server 2008’s RDP is pretty secure just as Server 2003’s RDP was if you always keep your machine up to date due to RDP being encrypted traffic.  But 3389 is often blocked on corporate firewalls.  So I elected to use SSH listening on port 443 to RDP into my lab.  How?  Read on…

After bringing up my server, installing Hyper-V, patching it, and all that other good stuff, I installed FreeSSHD which is a free download here.

The first thing I did was configure FreeSSHD to utilize port 443 instead of port 22.

There are two ways to authenticate when we SSH in.  One is Password Authentication and one is with Public Key Authentication.  I elected to utilize Password authentication only and because of that, I set it to required.  We can still use Public Key Authentication if we want but I decided Password Authentication is good enough for my needs.

I want to utilize port forwarding when I am utilizing an SSH client.  You will see how we take advantage of local port forwarding when I show our Putty configuration below.

We then have to add the account we want to grant access to use SSH.  Because this is a lab, I elected to use the Administrator account.  In a production environment, the Administrator account should not be used as it’s not a good security practice.

The next thing we’ll want to do is set up a port forwarding rule on our home router. Portforward.com is a great site to assist you in how to forward your public IP traffic to your private IP on your lab server for port 443.

This means that any time you want to SSH in, you’ll have to SSH into your public IP.  This can be annoying if you have a DHCP IP.  Instead of paying extra monthly fees for a static IP from your ISP and not contributing to the “we need to go to IPV6” cause, keep your DHCP address and use something like Dynamic DNS (DynDNS.org).

My home router is a Linksys router in which I am using the DD-WRT software.  After signing up for a DynDNS.org account, you can tell your router to update your Dynamic DNS account so you can always use DNS and know it’ll hit the correct public IP.

Now let’s load up PuTTY and check out the configuration.

We’ll want to specify the hostname we are connecting to as well as port 443 since that’s what SSH is listening on and that’s what we’re port forwarding.

The final configuration step of Putty is to set up our tunnels.

This tunnel essentially allows us to map port 3391 to port 3389. Essentially the way this works is when we PuTTY to our server, we have a secure connection to our server.  Because we enabled local forwarding on our SSHD server, we can create a tunnel rule in PuTTY so if we RDP to port 3391 it will map to 3389 on our server.

So after clicking Open we will get prompted for our Administrator credentials.  You must use an account in which you granted access in FreeSSHD.

After hitting enter and being connected, we can now launch our RDP client.  Because we used our forwarded port from 3391 to 3389, we will RDP to localhost:3391 and because we created that tunnel for our forwarded port, it will automatically connect to ServerIP:3389.  ServerIP is the IP that is defined in the Tunnel settings in PuTTY.

As we can see in the following screenshot, everything works as expected and we can now successfully connect to our lab via port 443, have it be secure, and not have to worry about a port being blocked as 443 is rarely blocked .

There’s one more thing to consider.  Because you are using port 443 for SSHD, you obviously won’t be able to use IIS on the box and have SSL use port 443 or use other applications that listen on 443.  I am using System Center Virtual Machine Manager 2008 which does utilize port 443.  When you install System Center Virtual Machine Manager, it gives you the option to modify the 443 port.  I elected to use port 543 instead.  Everything has worked perfectly and it’s been a month or so since I’ve had my lab up this way.

Share

Some Windows 7 and Server 2008 R2 Information

Mark Minasi over at Exchange Connections presented on Windows 7 and Server 2008 R2 and would like to share with you some information he bestowed onto myself and others.  In addition to what I am including below, Aaron Tiensivu will be coming out with quite a bit of information on Windows 7 and Server 2008 R2 in the coming days.  I’ll update this as he releases some information on his blog that he’s been writing up.

Now keep in mind that Windows 7 and Server 2008 R2 information has only just recently been announced to the public.  Some information below may be incorrect and might’ve been interpreted incorrectly.  So I would definitely not take the information below as 100% accurate until you see it in official Microsoft documentation.

  • Windows 7 will be released at the same time as Server 2008 R2 which is the next major server release.  Server 2008 R2 will be x64 only.  I am personally glad Server products are moving towards x64 only.
  • Aero is being renamed to Aero Shake.
  • Microsoft’s goal is that hardware that runs Vista will also run Windows 7
  • Vista drivers will also be Windows 7 drivers
  • XP has 260 methods to trick applications for application compatibility purposes.  Windows 7 will have 340 methods.
  • PowerShell 2.0 remoting will utilize WinRM for security instead of RPC.  The reason for this is WinRM runs on top of port 80 and is more security focused than RPC such as authentication.
  • .Net Framework will be installable in Server Core which will allow for Server Core PowerShell.
  • In Server 2008, Windows Deployment Services only runs at 1 speed and scales down to the slowest speed it detects on a line and uses that slow speed across the board.  In Server 2008 R2, Windows Deployment Services can run at 3 different speeds and multicast over these 3 different speeds.
  • Dynamic Driver provisioning will remove drivers that are not needed.  This allows you to put more images in 1 VHD (read next bullet) without having to worry about so many unneeded drivers being left on a machine.
  • VHD is being considered the new container format and is on track to replace CAB, WIM, and “maybe” ZIP in the future.
  • User Account Control (UAC) will have a slider (5 settings) to control how intrusive the setting is
  • Read only Distributed File System
  • Direct Access.  This is an Auto VPN type of functionality that uses IPSEC and SSTP.  This will require a Server 2008 R2 RRAS server.  This will be configured by an intuitive wizard.  One unfortunate thing is this will require IPv6.
  • Smarter memory allocation for applications
  • Non-miniport printer drivers (fewer but not all) are being moved from kernel mode to user mode to make the operating system more stable (no blue screens from drivers in user mode)
  • Microsoft is trying to push Powermanagement features such as making each default setting 10% more efficient.  This is a huge increase taking into account all machines that would run Windows 7.  One such advantage is the ability to move operations from 1 core to another if it will not impact performance and allow 1 core to be shut off to save power.  This is called core parking.
  • Branch Cache Lite – Allows to have a machine cache a file and server it out to workstations on its same subnet through Network Discovery Protocol (which replaced Computer Browser in Vista).  This is off by default but can be turned on through GPO.  Caches SMB, HTTP, and HTTPS.
  • Branch Cach Enterprise – Same as Lite but is Server Based.
  • Active Directory – New Domain Functional Level (no details given)
  • Active Directory – New Task Based Administrative Center based off of PowerShell.  All GUI tasks will show their PowerShell code just like the Exchange Management Console does.
  • Active Directory – Recycling Bin that will reanimate all attributes.  One of the problems with reanimating tombstones with a tool such as ADrestore is that when an object becomes a tombstone, it loses a lot of attributes but only really important attributes are retained.  With the recycling bin, all attributes that an object previously had would be retained and reanimated.
  • Active Directory – Best Practices Analyzer (hooray!)
  • Offline domain joining
  • Still no GUI for multiple password policies (I’m quite surprised at this although there are several community GUI tools to do this such as PowerGUI.)
Share

Exchange 2007 Mail Flow (DNS Records, Connectors, and TLS)

A lot of people are confused as to how exactly you should configure DNS for Exchange 2007.  But this isn’t just limited to DNS, but how do you set up your Send Connectors, Receive Connectors, how both connectors relate to DNS and the SMTP banner, and how to allow your Connectors to advertise TLS to the outside world.

That’s what the purpose of this article is for.  What FQDN should we assign to our connectors, what FQDN to add to our certificate to allow us to advertise StartTLS to the outside world to provide an increased chance that SMTP communications will be encrypted, and how to set up our DNS to ensure that our SMTP has a better chance to be accepted by the Receiving Server.

DNS A (HOST) Record

The first thing we want to do is configure an A record for our MX record to point to.  The MX record is a type of record which specifies that for a specific domain, you should contact a specific A record to send mail to.   Another name for an A record is a HOST record. When utilizing Windows DNS, the MX record will point to an A record.  For purposes of this lab, I will be showing you how to all DNS records via Windows DNS.  The first thing we will want to configure is an A record.  We will name this smtp.shudnow.net.  This A record will be pointing to the Public IP Address of the service that is accepting your mail.

Now why did I say mail service instead of mail server?  Well, there are services out there such as Exchange Hosted Services or Postini that will accept mail for your domain.  This is not your mail server.  Instead, your A record points to these hosted services which provide message hygiene services that then send appropriate messages directly to your Mail Server.

There are a couple benefits of utilizing these hosted mail hygiene services.  These include:

  • These services handle PTR records
  • They contain a team of spam experts to ensure services are at an optimal state
  • Datacenter redundancy
  • Always up to date antivirus definitions
  • They take care of the spam/antivirus which in return reduces the amount of viruses and spam that hits your network which can significantly reduce the amount of bandwidth coming into your environment

In our shudnow.net zone, let’s go ahead and create an A record for smtp.shudnow.net that points to 10.20.30.40.  This IP Address will be the Public IP Address that points to our Exchange Server.

Note: This is not any real IP address that I own.

You can create this A record by Right-Clicking our zone and choosing New Host (A) record.

We’ll enter the smtp name and set the IP address to 10.20.30.40.

We should successfully see our A record in our list of DNS entries.

DNS MX Record

Now that we have an A record, we will want to create an MX record to point to our A record.  An MX record is essentially a record that other mail servers will look for to see what server accepts mail for the domain the sending server is trying to send to.  So for instance, if someone sends a mail to Elan@shudnow.net, the sending server will look for the MX record of shudnow.net.  The MX record will show up as smtp.shudnow.net because the MX record points to the A record of smtp.shudnow.net.  The sending server will now do an IP address lookup of smtp.shudnow.net and obtain the IP Address and then establish a connection over port 25 to our receiving server.

In our shudnow.net zone, let’s go ahead and create an MX record.

You can create this MX record by Right-Clicking our zone and choosing Mail Exchanger (MX) record.

We will configure our MX record as such.  The reason we leave the top text field blank is because we are accepting mail for shudnow.net and we’re creating the MX record directly in shudnow.net.  If we were creating this MX record in the shudnow.net zone but were accepting mail for a child such as child.shudnow.net, we’d put in the word “child” in this text field.

We should succefully see our MX record in our list of DNS entries.

You can now see, doing an NSlookup query for the MX record of shudnow.net will successfully show the result as smtp.shudnow.net which points to 10.20.30.40.  And for those that are curious, we get the, “Can’t find server name for address…” because I don’t have a reverse lookup zone configured.

DNS PTR Record(s) and SMTP Banner(s) (Send/Receive Connector FQDNs)

A PTR record isn’t “always” necessary but there are some domains out there that will block you if you do not have a PTR record configured.  Take a look here.  According to Microsoft, the following domains will block you if you do not have a proper PTR record configured: AOL.com, Qwest.net, Mindspring, Earthlink, and Hotmail.  Sometimes the receiving domain will even block you if the PTR does not match the SMTP banner.  This is very rare though.  Now, some of you may be thinking, what is the SMTP banner?

When you telnet to your server over port 25, it will reply with “mail server communication speech.”  In the case of Exchange 2007, there are Receive Connectors and Send Connectors.  Because we made a connection to our mail server, our Exchange 2007 Server answered via the Receive Connector.

You will never want to modify the Default Receive Connector away from any of the following three names or you’ll have routing issues:

  • Blank
  • NetBIOS
  • Server FQDN

Instead, to modify the FQDN of the Receive Connector as I have, you must create a new Receive Connector with the Intended Use of Internet.  You can find the Receive Connectors in Server Configuration > Hub Transport > Receive Connector. This Connector will allow Anonymous Connections (not Relaying) while your Default Receive Connector will be utilized for internal routing.

Now you may want your Sending server to utilize the same smtp.shudnow.net name for sending.  In this case, we can create a Send Connector with our smtp.shudnow.net name.  You can find Send Connectors in Organization Configuration > Hub Transport > Send Connectors.  You won’t see any Send Connectors here by default since all Send Connectors to other Hub Transport Servers are hidden and are known as IntraOrg Connectors.

So let’s say our Sending Server is the same as our Receiving Server.  We can go ahead and create our PTR record so that 10.20.30.40 points to smtp.shudnow.net.  That way when we send to another server, that receiving server will see the communication coming from smtp.shudnow.net.  The receiving server will also see the communication coming from 10.20.30.40.  It “may” do a Reverse DNS lookup (checking PTR record) for 10.20.30.40.  It will see the smtp.shudnow.net name and pass the test.

Now here’s one thing to take into consideration. The majority of receiving servers out there just want there to be a PTR record point to a valid A record and it’s happy.  It’s seldom where a mail server will require the PTR record to match the SMTP banner.  But it’s still a good practice to have them match up if you can.

StartTLS

All Exchange 2007 by default is encrypted using TLS.  By default, Exchange 2007 utilizes self-signed certificates to utilize TLS.  I’m sure you guys/gals have heard this quite a bit.  But you may be wondering… how?  Well, I’ll tell you how.  There’s something called X-AnonymousTLS and StartTLS.  X-AnonymousTLS is utilized between Hub Transport Servers and between Edge Transport Servers and Hub Transport Servers (authentication only).  StartTLS is used for SMTP Clients, Domain Security, and when talking with Internet Mail Servers.

I won’t go into X-Anonymous much other than the fact the process of using a specific certificate is a bit different than what happens when advertising StartTLS.  You can check out this article to see the process.

For StartTLS, part of the process for selecting the certificate is by taking a look at what the Receive Connector FQDN is.  By default, it’s set at the FQDN of the server.  For example, in my lab my Hub Transport Server is SHUD-EXC1.  Because of this, the Receive Connector is set to SHUD-EXC1.shudnow.net.  During the certificate selection process, it will look for a certificate that contains the SHUD-EXC1.shudnow.net.

Now let’s not forget that you may have different Receive Connectors.  For example, if you have an Internet Only Receive Connector, SMTP communication with that connector will utilize a certificate that contains the FQDN set on that connector.

Now you may be thinking, how is Exchange 2007 secure by default if the StartTLS process looks for a certificate that matches the connector name?  Well, if no certificate is found, it’ll still revert to using a self signed certificate to offer StartTLS.  So, this is exactly how Exchange 2007 utilizes StartTLS by default.  So if you do want it to use an FQDN to advertise StartTLS, when you get a certificate from a third party vendor, include the name you want your SMTP banner set at.  Either way, your server should still offer StartTLS.

DNS Sender Policy Framework (SPF)

SenderID is an anti-spam technology that Exchange has on by default.  I won’t go into too much detail on how SenderID works and can be configured as Brian Tirch over at Exchange Genie does a great job at explaining it in addition to other Exchange Anti-Spam options.  You can check out his article here.  In short, SenderID will check for an SPF record from the receiving domain.  An SPF record will contain a list of servers that are allowed to send from a specific domain.

Many organizations do not set up SPF and because of that, SenderID is less restrictive when it retrieves an e-mail.  My domain @shudnow.net does have an SPF record set up for my mail servers.  Because of that, if you were to try to load up a server and send mail as @shudnow.net, that would be a huge red flag since I do have an SPF set up and your mail server is not on my SPF record.

Our current examples so far have used the example IP of 10.20.30.40.  So let’s set up an SPF record for this IP.  To help you out with the process, you can follow this web driven wizard here.

Let’s begin with Step #1 (duh!).  Enter your domain that you are setting up the Policy Framework for.  For this example, I will use “thisisatestdomain.com.”  The reason I am using this domain instead of shudnow.net, because as I said, I already have an SPF.  This wizard will detect that and not allow me to create a new one, but rather edit existing servers.

Since it didn’t find an SPF, it prompted us to let us know “No SPF Record Found”  and let’s us continue.

The next page has various options that you should go through and configure as you see fit.  One of the options I am configuring is Outbound Mail Server Addresses.

Once we have done this, we will obtain the information to put in our TXT file which we will publish in DNS.

So now going back to our InternetDNS server, we will go to our thisisatestdomain.com domain and publish our SPF record.  Most of the time, you’ll have a Service Provider that hosts external DNS.  If this is the case, all you need to do is submit a request to them to create an SPF and include a list of your sending servers.

You can create this TXT record by Right-Clicking our zone and choosing TEXT (TXT) record.

Choose TEXT (TXT)

We’ll need to put in the SPF Text information retrieved from the wizard.

We now have our SPF (TXT) Record created which helps people prevent spoofing your domain name in the future.

Share

Recovering from Server 2008 CCR Cluster Failure with Forcequorum

Server 2003 and Server 2008 Cluster Models are different in the following ways:

  • Server 2003 utilizes the Shared Quorum Model for Single Copy Clusters and utilizes Majority Node Set for Cluster Continuous Replication Clusters.
  • Server 2008 utilizes Majority Node Set for both Single Copy Clusters and Cluster Continuous Replication Clusters.  When using Single Copy Clusters with Server 2008, it is recommended to use Node Majority with Disk Witness.  When using Cluster Continuous Replication, it is recommended to use Node Majority with File Share Witness.

When working with Cluster recovery methods, the method differentiates a little bit from when using the Shared Quorum Model than using the Majority Node Set Model.

In this article, I will focus on recovering from Server 2008 Cluster Continuous Replication Site Failure (kind of — more info later).  I was debating on creating this article as a multi-part series for setting up CCR and then showing how to recover using Forcequorum, but decided not to.  This is because I believe Andy Grogan does a fine job in his how to set up CCR on Server 2008 that I decided not to.  You can read Andy’s great article here.

Forcequorum Changes in Windows 2003 and Windows 2008

One thing I do want to mention is that forcequorum in Windows 2003 and 2008 differentiate quite a bit.  While the functionality provides the same result, some things in the background are quite different.  First of all, in Windows 2003, /forcequorum can be used as maintenance switch.  In Windows 2008, this is no longer the case.  When running /forcequorum on a Windows 2008 Cluster Node, the paxos for the cluster is increased; you can call this inifnity.  What this means is, is that the node you run /forcequorum on becomes the master/authoritative node for any cluster joins.  Because of this, it is imperative that your cluster node you run /forcequorum on is a fully configured cluster node.  More information can be found on this here.  This to Tim McMichael for making me aware of this change to forcequorum in Windows 2008.

An example of the above would be the following:

You have a 4 node Single Copy Cluster.  You have installed Windows Clustering Services on all 4 nodes but you have only installed Exchange 2007 on 3 nodes.  On the 4th node you have not installed Exchange on, you run /forcequorum.  That 4th node is now the authoritative copy for all cluster nodes.  Whenever the cluster service starts, it performs a join operation.  Because the 4th node is now the authoritative/master node for cluster configuration, your 3 other servers will have Exchange failures because when their cluster service starts up the next time, the cluster information for Exchange on that server is wiped due to the authoritative copy on the 4th Exchange node being wiped. That is why, in Windows 2008, you need to ensure that the 2008 node you run /forcequorum on is fully configured.  Think of it as doing an authoritative copy on a Domain Controller that has been shut down for 2 weeks.  You’ll lose any password changes, accounts that have been created, accounts that were deleted will be back, and any other AD related information in the last two weeks will be back.

The Lab

While my lab is all in one site, the recoverability method is similar as it would be if it were a geographically dispersed cluster.  When the Exchange Servers in one site fails, that means the Active CCR in one site went down and the File Share Witness went down.  In a Geo-Cluster, your Passive and now the new Active Node (at least it should be the new Active… but read on) will not be able to start.

Why is this?  Well, a Majority Node Set Cluster requires 50% of the Nodes + 1 to be up.  Because 2/3 witnesses are down, the cluster services on your Passive Node will not start (which is what I meant by it should be the new Active).  Now what about the kind-of I spoke about earlier?  Well, since all the services are in one site, I will be skipping the method where I re-create the file share witness on a Hub Transport Server in the original datacenter and utilize the new FSW I already have created.  If you were indeed doing Geo-Cluster, you may want to re-provision the FSW back on the original node to get everything moved back over to the main site.  That’s the only difference.  This will make more sense as you read on as I show how to both move the FSW back to the original node and the method we actually do in regards to skipping that process.

So to re-iterate, my lab is in one site and will be showing you how to recover and provide additional information on what you would do if you wanted to re-provision your FSW back to a Hub Transport Server if you were failing back everything to your original datacenter. To start this process, I will pause my Active Node and my delete the file share witness that exists on my Hub Transport Server.  To recover, I will do a forcequorum on my second node, re-create the file share witness, have my cluster point to the new file share witness, bring up my old Active Node which will now be the new Passive Node, and have it point to the new file share witness.

The Environment

Before we dive into the process, let’s talk a little bit about the environment.  I have two Domain Controllers, one Hub Transport Server running on Server 2003 x64 R2 SP2, and two CCR Mailbox Servers running on Server 2008 x64.  All this is being run on Hyper-V managed by System Center Virtual Machine Manager 2008 RTM.

On SHUD-EXC1, our File Share Witness is located in the FSM_EXCluster file share.  This share has full permissions to our Cluster which is named EXCluster$.  Our Security/NTFS Permissions are set to Administrator and EXCluster$ full control.  Our Exchange CMS is named Cluster.  Yes… I know…  The names are backwards and the cluster name should be Cluster while the Exchange CMS should be EXCluster.  Oops I guess…

Taking a look at our Cluster in the Exchange Management Shell, we can see that our Cluster is currently healthy.

We can also see that moving the Cluster from SHUD-EXCN1 to SHUD-EXCN2 is successful meaning that the Cluster is indeed healthy.

I did move the Cluster back to SHUD-EXCN1 though just to make sure failover is working to and from both nodes.

Ok, hooray!  We have a successful and healthy cluster to test on.  So let’s get on with the good stuff.

Failing the Cluster

First thing I’m going to do is delete the file share.  We can see the share no longer exists on SHUD-EXC1.

Now, let’s pause SHUD-EXCN1 which is the current Active CCR Cluster Node.

We can check the services and event log on SHUD-EXCN2.  We can see that the Information Store service won’t start and we get quite a few event log failures such as the following (and there’s more than just what’s below).

Recover the Cluster on SHUD-EXCN2

So the first thing we want to do is a Forcequorum on SHUD-EXCN2.  You typically could bring up SHUD-EXCN1 but we’re acting as if SHUD-EXCN1 is having issues and we can’t get it up right now and we really need to get our cluster our to serve clients. Guidance on doing a forcequorum on both Server 2003 and Server 2008 for Exchange 2007 can be located here.

We will be performing the following steps to get our SHUD-EXCN2 running properly:

  • Provision a new share for FSW on SHUD-EXC1.  If you are doing a GeoCluster, you can do this in Site B which is where your Passive Node would be.
  • Force quorum on SHUD-EXCN2 by running the following command: net start clussvc /forcequorum
  • Use the Configure Cluster Quorum Settings wizard to configure the SHUD-EXCN2 to use the new FSW share on SHUD-EXC1.
  • Reboot SHUD-EXCN2.
  • Start the clustered mailbox server.

Provision New Share

We can run the following commands to re-create the folder for the FSW, share it out, and apply the correct permissions.

mkdir C:\FSM_New_EXCluster
net share FSM_New_EXCluster=C:\FSM_New_EXCluster /Grant:EXCluster$,Full
cacls C:\FSM_New_EXCluster /G BUILTIN\Administrators:F EXCluster$:F

Forcequorum on SHUD-EXCN2

Now is the time to force our cluster services to start on our soon to be Active Node which was previously the Passive Node.  We will do this by running the following command: net start clussvc /forcequorum.

Configure our new Cluster Quorum

Go into the Failover Cluster Management tool in Start > Administrative Tools.  Then Right-Click on our Cluster FQDN > More Actions > Configure Cluster Quorum Settings.

Choose Node and File Share Majority.  Click Next to Continue.

Enter the location for the new File Share.  Click Next to Continue.

You can go through the rest of the prompts and we will see the Cluster Quorum has successfully been configured to point to the new File Share Witness.

Remaining Steps

The remaining steps are very simple.  Reboot the node and start the Clustered Mailbox Server.  Upon restarting, you will see that the Cluster Service is successfully started.  Congratulations.  This means the connection to the File Share Witness is working because have have over 50% of our witnesses (2/3 is > 50%) online.

We can then verify we have Outlook Client Connectivity.  And as the screenshot shows, we do successfully have Outlook Connectivity.  Hooray!

Unfortunately though, we can still have our old Active Node SHUD-EXCN1 down as we can see in the Exchange Management Console.

Bringing SHUD-EXCN1 Back Online

Now we need to get SHUD-EXCN1 back online and in a healthy replication state.  If you did all the above in a real Geo-Cluster, you’d want to run the following steps:

  • Provision a new share on a HUB in Datacenter A.
  • Bring SHUD-EXCN1 online.
  • Reconfigure the cluster quorum to use the FSW share on HUB in Datacenter A.
  • Stop the clustered mailbox server.
  • Move the Cluster Group from SHUD-EXCN2 to SHUD-EXCN1.
  • Move the clustered mailbox server from SHUD-EXCN2 to SHUD-EXCN1.
  • Start the clustered mailbox server.

But because we’re running in the same site in the lab, we’re just going to skip the creation of the new FSW and use our existing one.  Because of this, our steps will be:

  • Bring SHUD-EXCN1 online.
  • Stop the clustered mailbox server.
  • Move the Cluster Group from SHUD-EXCN2 to SHUD-EXCN1.
  • Move the clustered mailbox server from SHUD-EXCN2 to SHUD-EXCN1.
  • Start the clustered mailbox server.

So let’s bring up SHUD-EXCN1.

Now on SHUD-EXCN2, in the Exchange Management Shell, we will run the following command to stop the Clustered Mailbox Server (GUI/CLI method here):

Stop-ClusteredMailboxServer -Identity Cluster -StopReason:Recovering CCR Node”

Let’s move the Clustered Mailbox Server to SHUD-EXCN1 using the following command (GUI/CLI method here):

Move-ClusteredMailboxServer -Identity Cluster -TargetMachine SHUD-EXCN1 -MoveComment “Moving CCR”

We will also need to move the default Cluster Group to SHUD-EXCN1 using the following command:

cluster group “Cluster Group” /move:SHUD-EXCN1

We willl then want to verify both the Cluster Mailbox Server (Cluster) and Cluster Group are both on SHUD-EXCN1.  Don’t forget that we did a Stop-ClusteredMailboxServer so we should see that Offline and the Cluster Group online.

We now want to start the Clustered Mailbox Server by running the following command:

Start-ClusteredMailboxServer -Identity Cluster

Now let’s verify that our Cluster is in a healthy replication state.

And to just make sure, let’s verify Outlook Connectivity still works.

Congrats, you now have a completely restored CCR Cluster!

Share

Next »