Vista SP1 causes a loss of functionality for certain applications
Thanks to a coworker of mine, Mike Nelson, for pointing this out to me:
http://support.microsoft.com/kb/935796
Elan Shudnow :: Feb.21.2008 :: Vista, Windows :: No Comments »
Thanks to a coworker of mine, Mike Nelson, for pointing this out to me:
http://support.microsoft.com/kb/935796
Elan Shudnow :: Feb.21.2008 :: Vista, Windows :: No Comments »
There seems to be some confusion as to how TLS connectivity to Exchange 2007 works. Many people think, that by default, Client to Server SMTP communication to Exchange 2007 is not encrypted and are asking, “How to secure Client to Server SMTP communication.” Well the answer is, it already is…. Let me explain.
By default, in Exchange Server 2007, there are two receive connectors. One is for Server to Server SMTP and the other is for Client to Server SMTP which is really used for POP3/IMAP clients to send mail via SMTP. I will talk a bit later about clients who are directly connected via MAPI. For this article, we will be talking about Client to Server SMTP.

When creating a Receive Connector, there are several Usage Types that can be selected:
Depending on which Usage Type you select, certain Authentication Groups will be selected. For example, for our scenario, the Client Usage Type will allow the Permission Group of Exchange Users which is exactly what we need.
In Exchange 2007, Microsoft wanted to comply with updated RFC standards and kept Server to Server SMTP communication over port 25 and segregated Client to Server communications over port 587. More details are formalized in RFC 4409.

So how do we really restrict only authenticated clients to use TLS when talking over the SMTP protocol with Exchange Server 2007. This is really a combination of the Authentication and Permission Groups Tab. First, we will have a look at the Permission Groups Tab.

As you can see, this Client Receive Connector only allows the Exchange Users group by default. This means that when a user connects to Exchange and authenticates, they are defined as an Exchange User and are allowed access to use this connector and use the SMTP protocol over the port defined in the Network Tab; this case being port 587. Once authenticated, the Exchange Users are granted the following permissions:
As you can see, the Exchange Users are allowed to Submit SMTP using this Receive Connector.
Now, we have to define if the Client to Server SMTP authentication for the selected Permission Groups is encrypted or not encrypted. This is done on the Authentication tab.

By default, Client to Server Authentication is encrypted using TLS via this Client Receive Connector. TLS is advertised and when using POP3/IMAP4, basic authentication, credentials will only be available after initiating a TLS encrypted connection.
As a side note, if you want to allow an anonymous application such as a Web Application to relay off of your Exchange 2007 server, you would do the following:
If you look at the Authentication Tab, only Transport Layer Security will be selected. This is called Opportunistic TLS which means that TLS will be accepted and is the preferred method for communication, but TLS will not be required.
To activate Anonymous users to use this connector for relaying, you must issue the following command:
Get-ReceiveConnector “Receive Connector Name” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”
Note: If you enable Anonymous users on a connector, that does not give them the permission to relay. The above command gives the Anonymous Logon account permission to Ms-Exch-SMTP-Accept-Any-Recipient (relaying) on the specified connector. That way, once you have allowed anonymous users to use that connector as well as grant them Ms-Exch-SMTP-Accept-Any-Recipient, they will now be able to relay via the specified connector.
If your application will be relaying SMTP using separate domain names, make sure you create the necessary Accepted Domains with the appropriate Internal Relay or External Relay settings for those domains. You do not want to choose Authoritative because Exchange will think it is authoritative for these mailboxes, and when Exchange sees these mailboxes do not exist, an NDR will be sent back to the sending server.
For more information about when to choose Internal Relay vs External Relay, visit the following site:
http://technet.microsoft.com/en-us/library/bb124423(EXCHG.80).aspx
Now what about clients who are connected to their Exchange 2007 mailbox via MAPI? Well that is encrypted by default as well. Outlook 2007 will connect to their Exchange 2007 mailbox through an encrypted manner.

If you want to enforce MAPI Encryption to your Exchange Server 2007 box, you can configure specific Exchange 2007 servers to force all MAPI connections to be encrypted by issuing the following command:
Set-MailboxServer ServerName -MAPIEncryptionRequired:$true
You can then install the Office Group Policy Templates to force all Outlook clients to use MAPI encryption:
Outlook 2003: http://support.microsoft.com/kb/826170
Outlook 2007: http://support.microsoft.com/kb/924617
Now I will show you how you can load the Outlook 2007 template into Group Policy, and force all Outlook 2007 clients to use MAPI Encryption.
From the link above, I downloaded the Office 2007 templates and extracted the outlk12.adm file. I will now open the Group Policy Management Console and import this ADM file. To do this, expand Forest > Domains > Your Domain > Group Policy Objects > Right-Click and choose New. From here, specify the name of the GPO you want created.

From here, we can right-click our new Outlook 2007 GPO and choose edit which will bring us into the Group Policy Object Editor. Expand User Configuration and Right-Click Administrative Templates > choose Add/Remove Templates…

Once we choose Add/Remove Templates, will be presented with the following screen:

Choose Add and navigate to the location to where you extracted the outlk12.adm file. You will then be presented with the Microsoft Office Outlook 2007 Group Policy settings in the Administrative Templates.

Navigate to Microsoft Office Outlook 2007 > Tools | Account Settings > Exchange > Enable RPC Encryption

Right-Click Enable RPC Encryption and choose Enabled and then select OK.

Once this is done, you will need to link the GPO to any of your Organizational Units or to the root container of your domain alongside your Default Domain Policy. This all depends on your Group Policy/OU design. After this, it will take 90-120 minutes for all your clients to obtain this new setting. This can be expedited by running the following command on your clients:
gpupdate /force
Elan Shudnow :: Feb.10.2008 :: Exchange :: 2 Comments »
Just an FYI for when the time comes that you deploy Exchange 2007 on Server 2008. The Windows Server Backup is not Exchange-aware and cannot be used for streaming backups or restores on Server 2008. Thanks goes out to Scott Schnol from Microsoft for this information. You must purchase a 3rd-party (or DPM 2007) VSS capable backup solution. If you do go to Server 2008, you can restore previous backups using the NTBackup Restore Utility available at the following URL:
And just to add some more information for those that haven’t used Windows Server Backup yet, you can’t back up the system state via the GUI. You have to use the CLI. You are also limited to full volume backups only. You cannot back up specific files/folders.
Personally, I think the Windows Server Backup leaves a lot to be desired.
Elan Shudnow :: Feb.07.2008 :: DPM, Exchange, Server 2008, Windows :: No Comments »
Microsoft Exchange Server 2007 Service Pack 1 Help:
The Exchange Server 2007 SP1 Help can help you in the day-to-day administration of Exchange. Use this information to guide you through Exchange Server 2007 SP1 features, tasks, and administration procedures.
http://www.microsoft.com/downloads/details.aspx?FamilyID=5eb0f9a0-2c49-4f2a-8a09-b981ed667821&DisplayLang=en
Microsoft Exchange Server 2007 Service Pack 1 Shell Help:
The Microsoft Exchange Server 2007 Exchange Management Shell Help file helps you use cmdlets in the Exchange Management Shell to perform day-to-day administration of Exchange 2007. You can view help in the Exchange Management Shell by using the Get-Help cmdlet. This Help file applies to the Microsoft Exchange Server 2007 Service Pack 1 (SP1) version of Exchange Server 2007
http://www.microsoft.com/downloads/details.aspx?FamilyID=0e14dd15-bb52-4b3f-9756-5146179a0809&DisplayLang=e
Elan Shudnow :: Feb.07.2008 :: Exchange :: No Comments »
Server 2008 as well as Vista SP1 have finally RTM’d. You can read more at the following URL:
http://blogs.technet.com/windowsserver/archive/2008/02/04/windows-server-2008-rtm.aspx
Elan Shudnow :: Feb.04.2008 :: Server 2008, Vista, Windows :: No Comments »
This download contains the latest XML and ExBPA.chm files. Use this package to update your existing installation of the Exchange Best Practices Analyzer. NOTE: If Internet connectivity is available, the Exchange Best Practices Analyzer will attempt to automatically update itself from the Internet. Where updates are being applied automatically, there is no need to download the Web Update Pack.
To find out which version of ExBPA.Config.xml is installed on your computer, click the ‘About Exchange Best Practices Analyzer’ link within the tool. The upper version number refers to the core application (e.g. 2.9.7926.0), the lower version is for the configuration XML file.
Visit the following URL to download the Web Update Pack:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4f2f1339-cbcd-4d26-9174-f30c10d7ec4c&DisplayLang=en
Elan Shudnow :: Jan.16.2008 :: Exchange :: No Comments »
A coworker of mine, Matt Wade, has detailed the steps on how to move the WinSxS and SoftwareDistribution (Windows Updates) directory here; thanks to a forum post created by Paul here.
For those who do not know what WinSxS and what issued it has caused, read Aaaron Tiensivu’s (another coworker of mine) blog post here.
In short, WinSxS is a directory which allows you to have distinct versions of the same DLL files. In previous versions of Windows, we all remember the annoying times when we installed a new application only to find it used a shared DLL file that another application needed. The bad part was, that both application used a different version. This could possibly cause the previously installed application to break if you chose to overwrite the DLL file. WinSxS’ existence was to prevent this behavior from occurring in Vista.
The problem here, is systems with smaller C:\ capacity get filled up very fast due to the WinSxS directory taking up a lot of space very fast. Thanks to Matt, we finally have a guide to help free up some of that space on C:\.
Elan Shudnow :: Dec.05.2007 :: Vista, Windows :: No Comments »