Tuesday, November 24, 2009

NTFS Inheritance Rule Change

Up until recently, NTFS permissions have followed these inheritance rules:

  • If a file or folder is copied to some other location, it will inherit the new location's NTFS permissions.
  • If a file or folder is moved to some other location on a different disk drive, it will inherit the new location's NTFS permissions.
  • If a file or folder is moved to some other location on the same disk drive, it will retain the original location's NTFS permissions.

One of the NTFS inheritance rules changed in Windows 2008, R2, Windows Vista, and Windows 7. Now if you move a file or folder, it will inherit the new location's NTFS permissions, even if the new location is on the same disk drive. This is a radical shift that you need to taken into account when you're moving files.

You can find a reference to this change in the Notes section in the Microsoft article "Inherited permissions are not automatically updated when you move folders".

Thanks to Murat Yildirimoglu, an MCSE and MCT in Istanbul, Turkey, for the article.

Friday, November 20, 2009

Microsoft Exchange Server 2010 Transport Server Role Architecture Diagrams


Microsoft has produced two Exchange 2010 Transport diagrams:
  • Exchange 2010 Hub Transport Extensibility

  • Exchange 2010 Hub Transport Role Architecture

Both diagrams are produced as PDF files that can be printed out in almost any size.

While I think these diagrams are visually beautiful, I rarely (if ever) refer to diagrams like this. They do, however, add a certain je ne sais quoi to the geekiness of any Exchange architect's office.

Wednesday, November 18, 2009

How to Test LDAP over SSL Connections

This article explains how to test that a directory server (typically, a Domain Controller or ADLDS server) is configured properly for LDAP/SSL connections. The tools described work with Windows-based systems (Windows XP and above).

First, you will need the LDP.exe utility. LDP is a Lightweight Directory Access Protocol (LDAP) client that allows users to perform operations (such as connect, bind, search, modify, add, delete) against any LDAP-compatible directory, such as Active Directory, ADLDS or ADAM.

LDP can be found for different platforms in the following locations:

To test LDAP over SSL connections, do the following:

  • Run the LDP utility (typically, click Start > Run > LDP)

  • In the LDP menu, click Connection > Connect

  • Enter the directory server name or IP address, the port (typically, 636 for secure LDAP), and check the SSL checkbox, as shown below, then click OK:


  • If the connection is successful, you will see a list of output similar to this:

  • Note that the connection string in the title of the LDP window indicates that the connection is made using ssl
  • If you get an error saying, "Cannot open connection," LDP cannot establish a secure connection to the directory server. In this case, it's very likely that the server is not configured properly for LDAP over SSL. Verify the server name/IP address and port number. You can also use the Portqry tool to verify that the directory server is listening on the correct port. Use "portqry /n servername /e 636" to check that servername is listening on endpoint (port) 636.

  • The following LDP output indicates that the connection failed because the certificate used in the SSL connection cannot be trusted:

ld = ldap_sslinit("dc01", 636, 1);
Error <0x0> = ldap_set_option(hLdap,LDAP_OPT_PROTOCOL_VERSION, LDAP_VERSION3);
Error <0x51> = ldap_connect(hLdap, NULL);
Server error: {empty}
Error <0x51>: Fail to connect to dc01.

I found a cool utility on Novell's website that can be used to view the SSL certificate on a remote directory server. Download the View Directory Certificate utility and extract the files to a temporary folder. Then run ViewDirCert.exe:

Specify the directory server or IP address and click View Certificate. The certificate details will be displayed in a new window. If the certificate was generated by an untrusted Certificate Authority (CA) or is a self-signed cert that the host does not trust, you will see a warning as shown below:

You can configure the host to trust this certificate by either adding the CA to the local machine's Trusted Root Certifications Authorities store or by importing the self-signed certificate into the local machine's Trusted Root Certifications Authorities store.

Wednesday, November 11, 2009

Speed up Outlook 2007 Access

I've heard several clients complain that Outlook 2007 takes too long to start up compared to previous versions of Outlook. In most cases I've found that this is because Outlook 2007 is configured to connect to Exchange using Outlook Anywhere, even on their corporate LAN/WAN.

Here's how to correct this:
  • Open Outlook and click Tools > Account Settings, or in Control Panel open Mail and click E-mail Accounts.
  • Double-click the Email account name that's using Exchange to edit its properties
  • Click the More Settings button
  • Click the Connection tab
  • Clear the Outlook Anywhere checkbox that reads, Connect to Microsoft Exchange using HTTP
  • Click OK > Next > Finish
  • Restart Outlook
Note: Also see this link for another possible cause of slow Outlook startup performance.

Exchange 2007 WILL Be Coming to R2

Reversing an earlier decision to NOT support Exchange 2007 on top of Windows Server 2008 R2, Microsoft has reversed their reversal and announced they WILL develop support for putting Exchange 2007 running on Windows Server 2008 R2 in an upcoming release…

See Supporting Exchange 2007 on Windows Server 2008 R2.

Tuesday, November 10, 2009

Exchange Server 2010 RTM Upgrade and Installation - Phase 3

This is the third and final phase of my Exchange 2010 / Windows Server 2008 R2 / Hyper-V migration. Phase 1 can be read here and phase 2 can be read here.

At this point, my Hyper-V host server is still running Windows Server 2008 SP2 and also functions as my Exchange Edge Transport server (currently Exchange 2007 SP2). It is hosting three VM guests: a Windows Server 2008 R2 domain controller/global catalog server; an Exchange 2007 SP2 server running the Hub/CAS/Mailbox roles; and a new Exchange 2010 server running the Hub/CAS/Mailbox roles. All mailboxes have been moved to the new E2010 server.

In phase 3, I will uninstalled the Exchange 2007 Edge Transport server role from the host, upgrade the host server to Windows Server 2008 R2, install the Exchange 2010 Edge Transport role, and decommission my last Exchange 2007 Hub/CAS/Mailbox server.

I began by uninstalling Forefront Security for Exchange Server from the Exchange 2007 Hub/CAS/Mailbox server. In order to do this, you must stop all the Exchange services and then uninstall the product using Programs and Features in Control Panel.

Next, I created a new Public Folder database on the Exchange 2010 Mailbox server and enabled replicas on the E2010 mailbox server using the Exchange 2010 Public Folder Management Console in the Exchange Management Console (EMC). I then removed all the Public Folder replicas from the Exchange 2007 Mailbox server role using the Exchange 2007 Public Folder Management Console in the EMC.

You cannot decommission an Exchange mailbox server that contains active mailboxes. They must be moved to another server or disabled. Since I had already moved all my user and resource mailboxes to the new Exchange 2010 server, all that was left was the system CAS mailbox which must be disabled (it cannot be deleted or moved). This is accomplished using the following command from the Exchange Management Shell (EMS):
Get-Mailbox -Database "EX\Mailbox Database" Disable-Mailbox
Now I'm finally ready to uninstall Exchange 2007 from the Hub/CAS/Mailbox server using Programs and Features in Control Panel. However, removal of the Mailbox role fails with the error, "Object is read only because it was created by a future version of Exchange: 0.10 (14.0.100.0). Current supported version is 0.1 (8.0.535.0)." I also discover I get the same error if I try to delete the E2007 Public Folder database.


After some research, I found that the only way to delete the "upgraded" Exchange 2007 Public Folder store is using ADSIEdit. This is detailed here, but the basic steps are to navigate to the Public Folder store in ADSIEdit and delete it, which I've done here.

Once the Public Folder database was removed, I ran the uninstallation again, which then succeeded. After Exchange 2007 was uninstalled, I completed the decommissioning by dis-joining the Exchange 2007 server from the domain and turned it off. I then tested mailflow to ensure that inbound/outbound SMTP email is working properly.
Next, I began the operating system upgrade of the Hyper-V host server by uninstalling Forefront Security for Exchange Server and the Exchange 2007 Edge Transport role. This went very smoothly with no issues.

In preparation for my OS upgrade, I shutdown and exported my two Hyper-V VMs to a new folder, H:\Exports. Exporting an VM exports the VM configuration, which includes the hardware, drives, networks (and most importantly, MAC addresses) to an XML file. This allows you to import the VM into a new Hyper-V host server without further configuration.

My process for upgrading the host server was to perform an in-place installation, not an upgrade. This is performed by booting to the Windows Server 2008 R2 DVD and choosing a new installation. Setup will warn that there is already a copy of Windows installed and prompt to continue. When you continue, setup will copy all the old user folders (Documents and Settings), Program Files, and the Windows folders to a new folder named C:\Windows.old, which can be accessed later from the new operating system. When setup completed, I was left with a base Windows Server 2008 R2 server.
I then installed the Hyper-V role and imported the VMs from H:\Exports. I started them up and verified that everything was running properly. I was very pleased to see that the VMs performed faster, due to R2's improved handling and performance of dynamic VHDs.

Next, I installed the Exchange 2010 Edge Transport server role on the host server, reconfigured my anti-spam settings, and created a new Edgesync subscription. After importing the Edgesync subscription in the Exchange 2010 Hub Transport server, I tested Edgesync and mailflow, which worked as expected.

I hope this series helps some of you out!

Friday, November 6, 2009

Fix for 'The server name is invalid' error when installing Exchange 2007 Management Tools


You may receive the following error when installing the Exchange 2007 management tools on a computer:

Error:
The server name is invalid. It contains characters other than 'A'-'Z', 'a'-'z', '0'-'9' and "-".

While the error indicates that the problem is with the server, it's actually with the name of the local computer where the Exchange 2007 management tools are being installed. The most common reason for this I've seen is when there's a underscore "_" in the local computer name.

The fix for this is to replace the exbpa.prereqs.xml file on the Exchange Server 2007 installation source with the RTM version of the file.  Here are the steps to do this:
  • Download the RTM version of exbpa.prereqs.xml from this blog (right-click the link and choose Save target as...) and save it to a temporary location
  • Disable automatic updating for Exchange 2007 setup. Otherwise, setup will automatically download the most recent version of the file and replace it. Run the following command at the CMD prompt:
reg add "HKCU\Software\Microsoft\Exchange\ExBPA" /v "VersionCheckAlways" /t REG_DWORD /d 0 /f
  • Copy the exbpa.prereqs.xml file you downloaded earlier to the \setup\serverroles\common\en folder on your Exchange 2007 installation media.
  • Now run setup and install the Management Tools, as usual.  You will still see the same error message, as shown above, but you will see an Install button instead of a Retry button.
When the installation is complete, remove the VersionCheckAlways registry key to reenable the automatic update feature using the following command:

reg delete "HKCU\Software\Microsoft\Exchange\ExBPA" /v "VersionCheckAlways" /f
Keep in mind that you may have to do this same procedure again in future update rollups and/or service pack updates.

Fix for Remote Desktop Gateway authentication error from clients

If you use Remote Desktop Gateway Manager (formerly, Terminal Services Gateway) in Windows Server 2008 R2, you may find that Windows clients are unable to authenticate to the RD Gateway server.

This happens because the default configuration in Windows Server 2008 R2 Remote Desktop Gateway is to request that clients send a statement of health before the connection can be made. If this option is selected and you do not have a Remote Desktop connection authorization policy (RD CAP) for Network Access Protection (NAP) configured, clients will be unable to connect to the RD Gateway. They will repeatedly be prompted for Gateway Server Credentials as shown below:



To fix this issue, ensure that you have a valid statement of health configured in NAP. Alternatively, as in the case of clients that cannot or do not provide a statement of health (I'm looking at you, Windows XP), you can disable requesting statements of healthy entirely. Here's how to do that:
  • Logon to the Remote Desktop Gateway computer and open the RD Gateway Manager (Start > Administrative Tools> Remote Desktop Services > Remote Desktop Gateway Manager)
  • Right-click the RDG server and select Properties
  • Click the RD CAP Store tab and clear the checkbox for "Request clients to send a statement of health", as shown below and click OK.

It may take a moment for the change to go into effect. Occacionally, I've had to restart the Remote Desktop Services service.