Some key fixes are: 

For more information on the Hotfix you can go to the page at http://support.microsoft.com/?kbid=979611.

Enjoy!

Anyway, If anyone out there is looking for a good skate Sharpener I recommend the Wissota Skate Sharpener.  I was able to to go to the company and pick up mine but they do ship.  While I was there I got a great demonstration on how the machine worked and the Sales guy even gave me more instruction then I could possibly ask for. There is an instructional DVD included with the Machine along with a lot of extra pieces.  I didn’t have to buy any thing more to get the machine to work.

So, if you are looking for a skate sharpener take a look at their web site, Wissota Manufacturing Company.  And no, I’m not getting paid for this or getting something for free.  I am happy with their product and wanted to recommend it to anyone out there Looking for a good Skate Sharpening Machine.

The Client setup involved a Windows 2003 domain controller that was acting up.  On this DC was their Root Certificate Authority for their entire Active Directory environment.  The client is small and does not have any special requirements for an Enterprise CA and wanted to move their CA to Windows 2008 Active Directory Certificate Services. 

The key principles here are that we need to move the private key associated with the Root Certificate Authority and also the Certificate Authority Database.  When moving a certificate Authority we need to preserve the CA name in the environment, otherwise nothing will work!  The clients will not be able to locate the CA nor will the Root certificate match up with the certificates.  Things just won’t be trusted.

To get started I reviewed the Support Article on How to move a certification authority to another server to backup the existing Windows 2003 Root CA Info.  I first used the Certificate Authority snap-in to backup the CA database and private key.  To perform the backup follow these steps:

• In the Certification Authority snap-in, right-click the CA name, click All Tasks, and then click Back up CA to start the Certification Authority Backup Wizard.
• Click Next, and then click Private key and CA certificate.
• Click Certificate database and certificate database log.
• Use an empty folder as the backup location. Make sure that the backup folder can be accessed by the new server.
• Click Next. If the specified backup folder does not exist, the Certification Authority Backup Wizard creates it.
• Type and then confirm a password for the CA private key backup file.
• Click Next, and then verify the backup settings. The following settings should be displayed:
• Private Key and CA Certificate
• Issued Log and Pending Requests
• Click Finish.

Next we have to save the registry settings.  To save the registry settings perform the following:

• Click Start, and then Run.  In the Run field type regedit and click Ok
• Locate and then right-click the following registry subkey, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration (While you are here, why not take a look at the settings, take a screen shot, make sure they match up in the end)
• Click Export
• Save the Registry file in the CA Backup folder that was defined above

Now that we have the database, certificate and registry backed up the next step was to remove Certificate Services from the old computer.  This process is pretty straight forward.  Go into the Control Panel, Add/Remove Programs, Windows Components and remove the Tick from Certificate Authority.  Note Be sure to remove the Certificate Authority from the old computer prior to deploying Certificate Services on the new machine.  If you deploy AD CS first the target CA will become unusable. 

Finally, rename the old server or permanently disconnect it from the network. 

In the step above I took the existing Domain Controller, removed the Certificate Services from it and then performed a DCPromo to remove Active Directory from the computer.  Once the computer was no longer a domain controller I renamed the old server.  I wanted to keep the server online for a fail back just in case, which wasn’t necessary since the move went over successfully!

Now, looking at where we stand right now I had the database, the Private Key and the certificate authority database backed up.  The data I backed up above should be copied to the new server that will be used for Active Directory Certificate Services.  This will need to be imported below. Now, the next step is to deploy Active Directory Certificate Services on the Windows 2008 domain controller.  BTW I should point out that when deploying Active Directory Certificate Services that you should use Windows 2008 Enterprise edition.  W2K8 Enterprise gives you more functionality of your Certificate Services.  For a list of features in Windows 2008 Standard vs Windows 2008 take a look at this link: Active Directory Certificate Services Step-by-Step Guide.  If you scroll down a bit you will see a comparison chart which will note which features are available with which version of Windows you use. 

Now, let’s move on to the part where we deploy and restore the Certificate Services.   Log on with local or enterprise administrator permissions to the CA computer and perform the followign:

• Launch the Service Manager for Windows 2008. 
• In the console tree, click Roles.
• On the Action menu, click Add Roles.
• If the Before you Begin wizard appears, click Next.
• In the list of available server roles, select the Active Directory Certificate Services check box, and click Next twice.
• Make sure that Certification Authority is selected, and click Next. (Note: If you are going to use Web Enrollment make sure to check this box.  You can always add it later but Why not add it now?  All the required roles will also be installed when you check this box since you will get a list of Add role service required)
• Select Enterprise and click Next.  (We are doing this because this is an Enterprise Root CA that will integrate with Active Directory.  Just like the one I decommissioned.  Best practice is to have a Standalone Root CA but given the size of this organization they are not too concerned with having a Standalone Root CA.)
• Specify Root  and click Next.  (If the CA you’re moving from was a Subordinate CA then we would want to tick the Subordinate CA option.  But since in my example this is a Root CA we are sticking with root.  Keep in main that if you’re coming from a Root CA or a Subordinate CA this option must match with what you’re coming from.)
• At this stage, you have a choice between creating a new private key or using an existing private key.  For a migration, on the Set Up Private Key page, select Use existing private key and choose Select a certificate and use its associated private key.

You should have something that looks like this:

Click Next and continue the steps below:

• If the CA certificate we backed up above has been installed on the computer, it will be listed in the Certificates box. Otherwise, click Import to import a certificate from the .pfx file created by exporting the CA certificate and private key from the source CA.
• Click Browse, and locate and select the file containing the certificate and private key exported from the source CA.
• Enter the password you selected when exporting the CA certificate and key from the source CA, and click OK.  Select the Certificate that was just imported and click Next
• When choosing your path you can either use defaults or browse to new ones.  Once done click Next
• Complete the installation of the AD CS
• Click Yes to accept the warning to overwrite AD DS. (This appears only if you are installing an enterprise CA.)

Congratulations, you’re almost there!  We have deployed Active Directory Certificate Services on Windows 2008.  There are still two more steps that must be completed.  This is the process of restoring the Certificate Authority Database that was backed up in the first section and restoring the registry component. 

To restore the registry simply locate the registry value that was saved above, right click the file and select merge.  This will import the Registry settings to the W2K8 server.  Next we have to restore the database.   You can check to make sure the settings were imported correctly by going to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration and verify your settings are there.  (Remember that screen shot?)

To restore the database and log files perform the following:

• Open Server Manager on the Windows 2008 Server.
• Expand Roles and then Expand Active Directory Certificate Services.
• Locate the name of the CA you just deployed.
• Right Click the CA name and select Restore CA…
• You will get a warning message that the AD CS cannot be running to perform this action.  Simply click Ok to stop AD CS.  AD CS will begin to stop
• On the Wizard click Next
• On the Items to Restore screen check the box Certificate database and certificate database log only.  Click Browse to locate the database that was copied over above.  (Note: I need to point out here that you select the folder you backed up to.  i.e. if you backed up the database and logs to C:\Temp\CABackup then this will be the folder you will restore from.  The backup process will create a subdirectory that it will look for during Restore, if you go one folder too deep the restore will fail.)  Once you have located your backup click Next.
• On the completion screen click Finish and the restore will begin. 
• Once the restore is complete you will receive a action box that asks if you would like to restart the AD CS.  Simply click Yes.  (We shouldn’t have any incremental backups since we are doing a migration.)
• Once the AD CS service is restarted we are good to go!

Well, what do you guys think?  Worth the effort?  Migrating to W2K8 AD CS will help your CA remain alive much longer.  During this process I also had to renew the CA Certificate which was pretty much easy. 

 I hope this article will help someone out there, I know I was able to get through it but had to go to a couple of different sources to get the exact process down.

 Enjoy!

The problem the client was experiencing in Exchange 2007 was that all outbound emails originating internally were being sent to the external journaling provider however, all inbound emails were not being forwarded to the journaling provider. 

The client contacted the Journaling provider and from a conversation it was determined that when an inbound message arrived to the Exchange Mailbox Server, it would be forwarded to the journaling provider from the original sender, the original sender being someone from outside the organization.  This immediately put up a red flag in my head.  I started to think, Exchange receives an email to send to a 3^rd party, from a person outside of this trusted organization.   Exchange was refusing to send the message!  So, the thought came into play, how to configure this thing to allow it to relay to the 3^rd party email server.  Anyone?  Anyone?  Ok, the solution was actually quite simple and once I understood what was happening it was easy to figure out.  I simply setup an Internal Relay!  Yup, that’s it.  The Internal Relay will allow Exchange 2007 to receive emails for a specific domain, query Active Directory for the mailbox and deliver the mail for that domain if it is found internally.  If the mailbox is not found internally Exchange will then Relay the email for the 3^rd party mailbox server specified in the Send connector which was already configured above!  Walla, problem solved!

For more information on what an Internal Relay Domain is click here.

Have a great day!

Reading the article I couldn’t help think that many clients are still concerned about space on their SANs and fear the idea of placing anything on local disk.  The idea in the article is placing your production mailboxes on Cheap Disk.  The only time a client or anyone should consider this is where you are using Database Availability Groups and have at least three servers in the DAG.  This will allow you to go backupless but also have all bases covered in your environment surrounding performance and recoverability. 

My only other beef though is Archiving.  The biggest question I get from clients is, “can I have my production mailboxes on one database and put the archived mail on cheap disk?”  Currently in Exchange 2010 an archived mailbox is stored on the exact same database as the users’ production mailbox. I have heard rumors that this is being looked into for future releases but nothing concrete.   What this means is that using SAN space which is typically RAID 10 or RAID 5 requires expensive disk for the production mailbox, which by default (if leveraged) archiving is also placed on expensive disk.   Explaining to clients that they can use local disk, have HA, but need at least three mailbox servers isn’t easy.  Not to mention that if you want multiple CAS in your environment with WNLB you need separate machines.  This is due to WNLB and MS Clustering cannot run on the same server.

Otherwise, given the way Exchange is deployed these days it is an enterprise solution.  There are times where departments will be included in a single database and other times where users are stored based on their last names.  I do love what they have done with Exchange 2007 and then what they have also done with Exchange 2010.  I just felt that I had to put in my 2 cents on the SIS discussion since I felt the post was a bit misleading.  While the applications are true, we have to consider real life usage and still address client concerns. 

Basically the problem they were having was when a voice mail was left for a user, it was not being delivered to the user.  Voicemails would pile up on the Unity server.  The recommendation was to reinstall Exchange 2007 on a W2K8 server WITHOUT R2.  The client decided to take a path to resolve the issue but I am not certain what they did.

On another note Exchange 2007 is not supported on Windows 2008 R2 yet, however I have heard rumors that if you install Exchange 2007 SP2 on Windows 2008 R2 if you run the install in Windows Vista Compatibility mode the install will work.  When will Exchange 2007 officially support Windows 2008 R2?  Well, Exchange 2007 SP3 will allow support for Windows 2008 R2.   Exchange 2007 SP3 should be released some time this year (2010). 

Moral of the story, do not put Exchange 2007 on W2K8 R2, and do not use Unity with Windows 2008 R2. 

I also understand that Cisco Unity does not support Windows 2008 R2 domain controllers.  Exchange 2007 SP2 will support Windows 2008 R2 domain controllers.  So, take your pick, but you can’t use Unity to query W2K8 R2 DCs. 

I hope this helps some people out there!  Thanks for visiting.

The client is deploying an Exchange 2007 SP2 environment leveraging a Single Copy Cluster (SCC) and two CAS/HUB servers. 

While testing the failure over process of the SCC we came to the point where using the manage clustered mailbox command in the Exchange Management Console or the Exchange Management Shell would not work.  We were receiving an error message that the Database failed to initialize.  The error log was huge, errors on creating the D drive (where the database was located), errors opening the database, mounting the database, it just wasn’t working!

I then suggested to go back and use the MS Failover Cluster Management tool.  We took a node off line, and failover worked.  How Odd!  This appeared to be an issue with permissions on the servers.  Something was prevent Exchange from performing the failover.  We then tried another failover vial the managed clustered mailbox command and I noticed that the shared disk drives were attempting to fail over to the passive node but they couldn’t!

We then proceeded to check permissions into the Windows Cluster and Exchange Cluster, adjusted a few settings but nothing worked.  Well, I then asked, is there a Group Policy blocking any time of assignment to “Manage auditing and security log”, he said no.  We checked Group Policy to be certain and there was nothing configured.  I then asked him to take a look at the local security policy on the system, sure enough, only the Administrators were in the group Manage auditing and security log.  Once adding the Exchange Servers to this group on each system the Single Copy Cluster was able to fail over with no problems! 

I am not certain as to why the Exchange Servers did not get added to the local security policy, there was nothing in group policy or anything on the system to over write this to my knowledge.  But none the less, it is very important to make sure the Exchange Servers do have access to the security setting.

Either way it was quite an interesting day at my client site, a few more issues came up but nothing as notable as the ones discussed here. 

Hope you have a great day!

The MOC 2007 R2 Group Policy Field Guide is a MS Word document that contains all the information an administrator wanted to know about MOC GPO settings but was afraid to ask. 

This doc has everything an Admin will need.  Here is a copy of the Appendix so you can see what options this document covers and is available for setting via Group Policy:

Appendix A. Policy Name Mapping Table

Also, if you’re looking for the Group Policy adm Template you can simply click here. 

Enjoy!

The first problem I noticed was the error message that stated Exchange was not part of an active directory site.  This caused me to think, why would an error come up like this.  My first instinct was to do a Gpresult /r (Windows 2008) which listed out all the information about the computer and user.  The Computer said it belonged to the site Default-First-Site-Name.  Ok, so the server was recognizing that it was a member of the AD Site, but why was exchange balking at the issue?  Well, I asked the IT Admin to open up Active Directory Sites and Services and took a look in there.  Looking over AD Sites and Services I noted the client had only one site configured, Default-First-Site-Name.  Thinking a little bit more about the situation I asked to see what subnets were configured for the site.  Well, upon review the site only had two subnets assigned to it.  Neither one of these Subnets included the subnet Exchange 2007 was in.   Talking to the Admin about this I learned that they had the same issue on the Hub Transport Servers and had to manually configure AD using ADSIEdit to insert the proper site name for the server to use!  Eww, not sure how this will impact their environment in the long run but when installing Exchange this should all be done automatically.  So, I had the admin add the Subnet to the AD Sites and Services and rebooted the mailbox servers, error gone, problem solved! 

The moral of the story above?  Make sure that you have your AD Sites and Services properly configured prior to deploying Exchange.  Oh yea, don’t forget, you need to have a domain Controller in the same AD Site as Exchange.  How the client ever got Exchange working is beyond me.  The workstation was seeing the AD Site but Exchange was not, hence the error. 

In the old versions of Exchange clients would connect directly to the mailbox server but that is no longer the case in Exchange 2010 (http://www.scottfeltmann.com/index.php/2009/10/26/sizing-exchange-2010-client-access-servers).  This leads us to the reason why CAS arrays are so important in the Exchange 2010 environment.  In Exchange 2010 clients now connect directly to the CAS.  The CAS then will proxy the client to the mailbox server.  This means that all outlook client connectivity is now routing through the CAS.  When not using the CAS array the outlook client will connect directly to the CAS and remain connected to that CAS.  In the event of an outage the Outlook client will lose connectivity to the Exchange Mailbox Server and will not be able to fail over to another CAS in the Active Directory Site since it has already established a connection to a CAS which is now down.  How does the Outlook client find the CAS?  When a CAS is deployed in Active Directory it will create a service connection point (SCP).  This SCP then tells clients the clients via autodiscover how to find a CAS.  If an organization has multiple CAS then there are multiple SCP created in AD.  This process holds true in both Exchange 2007 and Exchange 2010.  The difference is Exchange 2010 has the ability to create Client Access Array’s.

So, you’re asking yourself, ok, what is a Client Access Array?  Well, I’m glad you asked!  In Exchange 2010 Microsoft introduced a new concept for High Availability for the Client Access Servers called a CAS Array.  What organizations are now capable of doing is configuring a set of Client Access Servers to act as one by using Network Load Balancing (NLB), either Windows or a Hardware Load Balancer will do.  When using NLB admins create a DNS record that points to a Virtual IP address (VIP).  Behind this VIP will be the Client Access Servers.  You may have one or twenty.  Keep in mind though, if using one, when that server goes down, users lose connectivity.  (I’m assuming that you know how to NLB the Client Access Servers, unfortunately I don’t have anything written on setting up NLB but there are some good articles out there.)  So, if you have three CAS in your environment you are capable of creating a new array which will include all three of these servers.  The array will point to the NLB hostname which will then route the traffic to one of the CAS behind the NLB URL.  In the event that a CAS should go offline, and since the client is connecting directly to the NLB URL and IP the client will be redirected to a functioning CAS and be able to maintain their connection!

Now that we have an idea of what a Client Access Array is the next logical step is creating the array!  In order to create a new Client Access Array we will use the new command of “New-ClientAccessArray”.  This command will create an object that represents a load balanced array of CAS within a single Active Directory Site.  Keep in mind, that each array is specific to the AD site.  This means if you have multiple sites with Client Access Servers you can create arrays specific to that site.

The following example is the command for creating a new array, this command will create a server array named cas.scottfeltmann.com:

New-ClientAccessArray –FQDN cas.scottfeltmann.com –Name “cas.scottfeltmann.com” –Site “HQ”

The Fqdn parameter specifies the fully qualified domain name (FQDN) of the Client Access server array. (Required)

The Name parameter specifies the name of the Client Access server array.
The Site parameter specifies the Active Directory site to which the Client Access server array belongs.  (Required)

In the event that exchange databases already existed prior to the creation of the CAS array you will need to configure the databases to point to the new array.  To do this you can use the following command:

Set-MailboxDatabase Databasename –RpcClientAccessServer “cas.scottfeltmann.com”

Otherwise, when a new database is created it will automagically detect the Client Access array and point users to the load balanced URL.

In close if you’re looking for some HA you will want to use the Client Access Array to provide the highest level of redundancy for your Outlook client connection.  Keep in mind you will still need another form of HA for OWA and ActiveSync.  ISA 2006 presents a group solution for this process as well since ISA can direct traffic to multiple Exchange Client Access Servers.  For more information on NLB Exchange 2010 CAS see my link here: (http://www.scottfeltmann.com/index.php/2009/10/21/network-load-balancing-recommended-for-exchange-2010-cas-public-facing-internet-facing-and-internal/)

Edit:

I would also like to point out that if you would like to remove a CAS from a CAS Array you will need to remove that Client Access Server from the NLB array.  This can be done either through WNLB if that is what you are using or via your NLB appliance.  Simply remove the desired server from the NLB and that server will no longer be included in the CAS Array.