The things that are better left unspoken : Microsoft Exchange Server

Pictures of the NGN Tablet Day

Sander Berkouwer — Thu, 18 Apr 2013 12:08:46 GMT

Yesterday, the Dutch Networking User Group organized the Tablet Day at the Reehorst in Ede, the Netherlands. Dave and I presented a 45-minute session on device management through ActiveSync. The whole day was packed with sessions from many speakers and it was a great success with good drinks and a dinner afterwards.

Some people took pictures during our session, so I thought of sharing some of them with you in this blogpost.

We had a big room with nice natural lighting, that felt like a breath of fresh air in contrast to the main auditorium of the Reehorst. The room was filled with 150 seats and, as you can see in the picture below, the majority of them were used by people attending our session:

Since this was the third time Dave and I presented on the topic, we felt pretty confident and had a lot of fun discussing the IOS 6.1 ActiveSync bug, the effects of ActiveSync settings on various tablet and phone models and the missing Swipe Password API on Android-based devices:

Active Directory Visibility Modes

Sander Berkouwer — Tue, 09 Dec 2008 01:02:08 GMT

While being involved with my company’s Hosted Messaging and Collaboration (HMC) implementation I ran into the Active Directory List Object Access Mode, set through the DS-Heuristics attribute. I decided to give you a little rundown of this mode and the other (default) Active Directory Visibility mode, how they’re different, how to enable (and disable) one or the other and what you can do with them in your environments.

About HMC

Microsoft’s Solution for Hosted Messaging and Collaboration (HMC) is a multitenant environment, that Microsoft partners can use to offer Microsoft Exchange, Microsoft Sharepoint and Microsoft Office Communications Server (OCS) to customers from within a datacenter. The current version is HMC 4.5, offering Exchange 2007 with Service Pack 1, Sharepoint Services 3.0 with Service Pack 1 and Office Communications Server (OCS) 2007.

Hosted Messaging and Collaboration (HMC) can be seen as the partner option to Business Processes Online Services (BPOS), in which Microsoft offers customers access to Exchange Server, Sharepoint Services, Live Meeting Server and (soon) Office Communications Server.

About DS-Heuristics

The DS-Heuristics attribute in Active Directory can be used to make global changes to the behavior of Active Directory and Active Directory controllers throughout the entire Active Directory forest. Settings include the behavior of Ambiguous Name Resolution (ANR) search filters, the capabilities within anonymous LDAP connections, the behavior of the User-Password attribute, the groups protected through AdminSDHolder and of course the visibility mode, the subject of this post.

Active Directory Visibility Modes

Within Hosted Messaging and Collaboration (HMC) a hosting provider uses a single Active Directory domain to deliver security services to multiple customers, which the provider facilitates by creating separate organizational units (OUs) for each client. Since the Service Level Agreement contains a couple of privacy related clauses the hosting provides requires that clients not be able to learn of the existence of other clients. The service provider is required to control the visibility of each customer's OU to users of that customer only. In such scenarios organizations need a way to tightly control visibility.

Active Directory offers two visibility modes:

List Child Access mode
List Object Access mode

The first mode is the default Access mode in Active Directory. Changing the visibility mode to List Object Access Mode changes the way security is handled. In the first mode when a user has the List Child permission in Active Directory it can see the child object and every object underneath it. In the second mode the user needs to have explicit List Object permissions on each and any object as well as the List Child permission to view objects.

By default, the Authenticated Users group is granted the List Contents access control right over objects in a domain. With List Object Access mode enabled access to other Organization Units (OUs) can be prohibited so users from one company (represented by an OU in the shared Active Directory) can only see users from their own company. To achieve this remove the List Contents access permission on containers of other companies and grant the List Object permission to the objects that the users or groups should be able to list.

Changing the Visibility Mode

To enable List Object Access Mode perform the following steps:

Log on to a Domain Controller using an account that is a member of the Domain Administrators group.
On Windows Server 2003 install the Windows Server 2003 Support Tools, available on the Windows Server 2003 Server CD.
On the taskbar, click Start, point to Run, type MMC, and then press Enter.
Click File, and then click Add/Remove Snap-in.
Click Add, select ADSI Edit, and then click Add.
Click Close, and then click OK.
In the Select a well known Naming Context drop-down box, select Configuration, and then click OK.
Expand Adsiedit.
Expand Configuration.
Expand CN=Configuration, DC=YourDomainName, DC=YourTLD.
Expand CN=Services and CN=Windows NT.
Right-click Directory Service, and then click Properties.

Select the dsHeuristics attribute, and then click Edit.

You can now change the value to your desired mode, by editing the third character of the value.

Visibility Mode Value

List Child Access mode (default)
0

List Object Access mode
1

The dsHeuristics value sets a couple of behaviors. By editing the third character of the Directory string you set the Visibility Mode. When the third character is 0 or absent (by default the value for dsHeuristics is 0, and thus the third character is absent) the Visibility Mode is set to List Child Access mode. (default)

When done click OK twice and close the MMC.

Concluding

Changing the visibility mode of your Active Directory can significantly help blocking access to certain parts of your Active Directory. It’s definitely worth a look in highly secure environments, like multitenant environments.

AdminSDHolder

Exchange (2003) System Manager for Vista

Sander Berkouwer — Wed, 06 Aug 2008 12:15:25 GMT

Remote Management incompatibility is one of the biggest problems with Windows Vista, Windows Server 2008 and Exchange Server 2007 on one side and Windows XP, Windows Server 2003 (R2) and Exchange Server 2003 on the other side.

Up until today the table below gives an accurate picture of this problem:

Compatibility chart	Exchange Server 2003 SP2 Exchange System Manager	Exchange Server 2007 Management Console	Exchange Server 2007 SP1 Management Console
Windows XP	Yes	Yes	Yes
Windows Vista	No	No	Yes

It boils down to not being able to manage Exchange Server 2003 remotely from Windows Vista. (more info here)

ESM for Windows Vista

Today the Exchange System Manager for Windows Vista appeared in the Microsoft Download Center. It corrects this situation: You can now manage Exchange Server 2003 remotely from Windows Vista.

Prerequisites

To make the Exchange System Manager for Windows Vista work you need to make sure:

Your server is running Exchange Server 2003 with Service Pack 2
Your workstation is running Windows Vista or Windows Vista with Service Pack 1
Your workstation has the Windows Server 2003 ServicePack 1 Administration Tools Pack or Windows Server 2003 R2 Administration Tools Pack (x86) installed.
Your workstation has the Internet Information Services (IIS) 6 compatibility module installed
Your workstation has the latest MAPI CDO package, “Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1” installed.

Notes

While playing with the bits I noticed the following:

The Release notes supply good information on prerequisites and known issues
You cannot install ESM for Windows Vista on Windows Server 2008
You cannot have Microsoft Office Outlook installed on the workstation you want to use with the Exchange System Manager
You can install ESM for Windows Vista on 64bit editions of Windows Vista

Concluding

Many more management incompatibilities exist, but I believe the most notable was solved today. Now let's hope Microsoft solves the other problems as well.

Exchange Server 2007 SP 1 is here

Sander Berkouwer — Thu, 29 Nov 2007 21:25:53 GMT

Microsoft released Service Pack 1 for Exchange Server 2007 today, after formally announcing it yesterday.

New in Service Pack 1

Service Pack 1 for Exchange Server 2007 comes packed with all sorts of fixes and patches, but also some neat features and adjustments to answer the needs of administrators coming from earlier versions of Exchange Server. This Service Pack also clearly shows the merge of the Real Time Communications Team (responsible for Live Communications Server) and Exchange Team, because the Service Pack enables Exchange Server 2007 to play nicely with Office Live Communications Server 2007.

Patches

The Microsoft Exchange Team has vowed to bring patches and fixes to Microsoft Exchange Server 2007 in Update Rollup packages every six to eight weeks. Service Pack 1 includes all the fixes in Update Rollup 5 for Exchange Server 2007, which itself contains all of the updates contained in the previous Update Rollup packages.

Features

Since Microsoft clearly left the path of bugfixes-only Service Packs since Windows XP Service Pack 2 every Service Pack included new features, additions or new management capabilities for the affected product. Service Pack 1 for Exchange Server 2007 also clearly comes with tons of new stuff:

Windows Server 2008 support
Office Communications Server 2007 support
Improvements to Unified Communications
Standby Continuous Replication (SCR)
Internet Protocol version 6 (IPv6) support
Expanded support for clustering in the Exchange Management Console
POP and IMAP configuration in the Exchange Management Console
SendAs delegation in the Exchange Management Console
Delegation Wizard scenarios in the Exchange Management Console
New and improved Outlook Web Access
(with S/MIME, Office 2007 format compatibility, server side rules, personal distribution lists, a monthly calendar view, deleted items recovery and new themes)
Additional languages for spell checking in Outlook Web Access (Arabic and Korean)
New Exchange ActiveSync policies

Adjustments

Some commands and features got deprecated with the arrival of Exchange Server 2007. Microsoft's strategy to turn Public Folders into Sharepoint Sites and finally getting rid of those horribly unusable PST files didn't quite catch on though. Reversing these changes in my opinion is a good answer to many Exchange administrators prayers:

Public Folder Management in the Exchange Management Console
Public Folder access through Outlook Web Access
(Official) support for exporting and importing mailboxes from and to PST files

Note:
I still suggest Exchange Administrators to gradually convert their public folder structure to Sharepoint websites.

Performance

As with other recent Service Packs this first Service Pack for Exchange Server 2007 contains some big performance boosters. One thing we noticed was a 30% increased throughput within ActiveSync which is a huge performance boost.

Deployment

Deployment of Service Pack 1 for Exchange Server 2007 is easy. As long as you take care of the prerequisites you'll be fine running the installer. New deployments of Exchange Server 2007 can be done using slipstreamed media. (which is also new!)

The download for Exchange Server 2007 Service Pack 1 comes in two flavors:

a 32bit installer package (E2K7SP1EN32.exe, weighing 840 MB)
a 64bit installer package (E2K7SP1EN64.exe, reaching nearly 855 MB)

You can use the 64bit package to update your production Exchange Servers. The 32bit package can be used to update your 32bit test Exchange Servers, but more importantly the Exchange Management Console installations on your desktops. Don't forget to update those as well, since a lot of the new functions are focused on the Exchange Management Console.

Server Core implications

Exchange Server 2007 with Service Pack 1 can now be deployed to Windows Server 2008 in a supported manner. Please note that installing any of the Exchange Server 2007 roles is not supported on Server Core installations of Windows Server 2008.

Concluding

One might argue Exchange Server 2007 wasn't ready for prime time when it was launched (it wasn't far from the truth, but that's besides the point) because it lacked support for a lot of deployment, management and usage scenario's Exchange Systems Managers had got used to in the Exchange 2000 Server and Exchange Server 2003 eras.

With Service Pack 1 for Exchange Server 2007 Microsoft delivers on its promise to provide a rock-solid, truly manageable, truly usable communications platform.

Eat that, Bonsai!

Exchange Server 2007 and the Active Directory, Part 5

Sander Berkouwer — Sat, 10 Mar 2007 01:18:00 GMT

Microsoft Exchange Server 2007 has a new trick up its sleeve in combination with Microsoft Office Outlook 2007 and Windows Mobile 6: Exchange AutoDiscover Service. You can use this feature with your Domain Naming System (DNS) implementation, but this feature is even more functional when used in conjunction with Active Directory.
(Just like everything you use in your daily life...)

Before AutoDiscovery

In Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003 environments you had to use elaborate %username% tricks, work with the Microsoft Office Custom Installation Wizard, Newprof, Profgen or any of the hundreds tools and scripts available for the purpose of automatically configuring Microsoft Outlook to use your Microsoft Exchange messaging infrastructure.

Better together

Microsoft introduced the marketing phrase "better together" for Microsoft Office Outlook 2003 and Microsoft Exchange Server 2003 and they told us Knowledge and Information Workers could benefit from increased performance and availability features, like:

Improved MAPI compression
Unicode Offline Folders (OST files)
RPC over HTTP(s)

With Microsoft Office Outlook 2007 and Microsoft Exchange Server 2007 the phrase "Better together" gets reused. The dust is blown off, it got a good polish and it looks like brand new! This time Microsoft uses it to sell the new featureset, including:

Improved Out of Office (OoO) Assistant
New Scheduling Assistant
AutoDiscover
Instant Search
Sharing policies
Managed E-mail folders
AutoDiscover feature

How it works

To make this clear right from the start: AutoDiscover is a web service. It is served by Microsoft Exchange Server 2007 boxes with the Client Access Server Role on them. (also known as a Client Access Server) A DNS record (optional) and a Service Connection Point within Active Directory point to the AutoDiscover server.

From the client part AutoDiscover-enabled clients use the information within your DNS zone to find the server hosting the Web Service. With AutoDiscover-enabled clients I mean:

Microsoft Outlook 2007 installations on PC's within your organization
Microsoft Outlook 2007 installations you want to use with Outlook Anywhere (formerly known as RPC over HTTP clients)
Microsoft Windows Mobile 6 devices

Server-side

Let's look into each of the server-side components that make up the AutoDiscover Web Service a bit closer:

Domain Naming System (DNS) or Active Directory Lookup

When you install Microsoft Exchange server 2007 the installation program creates an Active Directory object in your Active Directory known as a Service Connection Point.

You can also make a DNS A record in your Forward Lookup zone within your DNS Management MMC Snap-in (dnsmgmt.msc) pointing to the IP address of your Microsoft Exchange Server. The name of this record would be autodiscover.

Using Active Directory Integrated DNS in your enterprise organization makes this task easy: The changes you make in DNS will be replicated through your organization without a hitch and in a multi-master manner.

When you plan multiple Microsoft Exchange Servers with the Client Access Role I suggest you make multiple DNS records with the name autodiscover to point to these servers. That way you won't end up with a single point of failure (SPoF) for this service. the Client Access Servers will point the connecting client to the appropriate Exchange Server.

Using the automatically created AutoDiscover Service Connection Point is the preferred way to go, because you can use it in conjunction with Active Directory sites. The Exchange Team said Microsoft Exchange Server 2007 is Active Directory site-aware and it shows again.

If you want to enable Microsoft Windows Mobile 5.0 MSFP or Windows Mobile 6.0 devices and Outlook Anywhere clients you should also make a DNS A record in your public Forward Lookup Zone, resulting in a autodiscover.youremaildomain.com DNS record pointing towards a public IP address where you'd make the AutoDiscover IIS Virtual Folder available through HTTP over SSL (HTTPS) and make sure you publish it with a valid SSL Certificate to avoid unnecessary errors.

The Autodiscover Virtual Server

Within the Internet Information Services (IIS) Manager on your Microsoft Exchange Server with the Client Access role (known as a Client Access Server) you'll find an IIS Virtual Server called 'autodiscover'. It contains multiple files and subfolders:

Folder: Help
Folder: Bin
Autodicover.xml
default.aspx
global.asax
web.config

Managing AutoDiscovery Services

The Microsoft Exchange Management Shell provides some splendid CMDlets to manage the Autodiscover Service on Microsoft Exchange Server 2007 Client Access Servers:

New-AutoDiscoverVirtualDirectory and Remove-AutoDiscoverVirtualDirectory to create new AutoDiscover Virtual Directories or to remove the original or manually created AutoDiscover Virtual Directories on your Client Access Servers
Test-OutlookWebServices with the -ClientAccessServer switch to test your AutoDiscover Services.
Set-AutoDiscoverVirtualDirectory lets you configure the behavior of your AutoDiscover Virtual Directory (so you don't have to edit your Autodiscover.xml manually), while Get-AutoDiscoverVirtualDirectory retrieves settings from AutoDiscover Virtual Directories.
You can make or delete the AutoDiscovery Services' Service Connection Point in Active Directory with the Export-AutoDiscoverConfig CMDlet.

Besides the cmdlets to configure individual AutoDiscover Virtual Directories there are four cmdlets that grant you the ability to manage the AutoDiscoverConfig object under the Global Settings object in the Active Directory directory service. These are New-OutlookProvider, Remove-OutlookProvider, Get-OutlookProvider and Set-OutlookProvider. These settings can also be managed using AdsiEdit.msc from the Support Tools if that is your preferred way of editing the Exchange Organization within Active Directory, but I must admit that the more granular way of granting permissions in Exchange Server 2007 appeals to me more.

Last but not least the Set-ClientAccessServer CMDlet offers you the chance to enter the AutoDiscoverSiteScope option to define for which Active Directory sites the Autodiscover service is authoritative.

Conclusion

The Outlook 2007 AutoDiscover web service is awesome!

Deploying Exchange Server 2007

Sander Berkouwer — Wed, 07 Feb 2007 11:59:00 GMT

Microsoft today released a couple of documents to aid in the deployment of Microsoft Exchange Server 2007. These Microsoft Word compatible documents (no XPS documents this time) provide descriptions and overviews of features, guidelines for planning, and steps for deploying an Exchange 2007 organization.

They correspond with the predefined four supported deployment scenarios.

Deployment Scenarios

You can categorize your Exchange Server 2007 deployment into one of the four supported Exchange organization models:

Simple Exchange Organization
The Simple Exchange Organization contains either a single Exchange server that provides all Exchange services and stores all Exchange data for the entire organization, or multiple Exchange servers in a topology that includes redundant directory servers and an Edge Transport server in a perimeter network.
Standard Exchange Organization
The Standard Exchange Organization builds upon the Simple Exchange Organization by deploying multiple computers running Exchange.
Large Exchange Organization The Large Exchange Organization is the largest organization model that can be deployed in a single Active Directory directory service forest.
Complex Exchange Organization The Complex Exchange Organization is the only model that includes multiple Active Directory forests or the use of synchronization technology.

Deploying a Simple Exchange Server 2007 Organization

Of the four defined organization models for Microsoft Exchange 2007 (simple, standard, large, and complex), the simple Exchange organization represents the most basic topology into which Exchange 2007 can be deployed. The simple Exchange organization contains either:

A single Exchange server that provides all Exchange services and stores all Exchange data for the entire organization.
Multiple Exchange servers in a topology that includes redundant directory servers and an Edge Transport server in a perimeter network.

This document will provide the planning and deployment information you need to get your simple Exchange 2007 organization up and running.

Deploying a Standard Exchange Server 2007 Organization

Of the four defined organizational models for Exchange 2007 (simple, standard, large, and complex), the standard Exchange organization represents the most common topology into which Exchange 2007 is deployed. As messaging service needs grow beyond the resource limits of a single computer, separation of Exchange 2007 services onto multiple computers becomes the next topological division: the standard Exchange organization. The standard Exchange organization builds upon the simple Exchange organization by deploying multiple computers running Exchange.

This document will provide the planning and deployment information you need to get your standard Exchange 2007 organization up and running.

Deploying a Large Exchange Server 2007 Organization

Of the four defined organization models for Exchange 2007 (simple, standard, large, and complex), the large Exchange organization is the largest organization model that can be deployed in a single Active Directory directory service forest environment.

This document will provide the planning and deployment information you need to get your large Exchange 2007 organization up and running.

Deploying a Complex Exchange Server 2007 Organization

As its name implies, a complex Exchange organization represents the most intricate topology into which Exchange 2007 is deployed. Of the four defined organization models for Exchange 2007 (simple, standard, large, and complex), the complex Exchange organization is the only model that includes multiple Active Directory directory service forests or the use of synchronization technology.

This document will provide the planning and deployment information you need to get your complex Exchange 2007 organization up and running.

Concluding

The documents in this post are very good references for your Microsoft Exchange deployment(s). I suggest you read the document corresponding to your Exchange organization model when you're planning a deployment.

These documents are deployment-specific compilations of several Exchange 2007 Help topics and are provided as a convenience for people who want to view the topics in print format. To read the most up-to-date deployment topics, visit the Exchange Server 2007 Library.

Exchange Server 2007 and the Active Directory, part 4

Sander Berkouwer — Mon, 11 Dec 2006 02:20:00 GMT

With Microsoft Exchange Server 2007 comes a new security model to publish your servers to the Internet: Microsoft Exchange Server 2007 boxes configured with the Edge Transport Server Role. This new model replaces the current Front-End / Back-end model.

Front-ends and Back-ends (2000-2003)

In the last year two of my projectteams implemented Microsoft Exchange Server 2003 Front-end / Back-end configurations. In the Front-end / Back-end configuration, available in both Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003 the basic principal is to divide server roles. The distinction is made between a front-end server that accepts requests from clients and then proxies them to an appropriate server for processing, making this effectively a Back-end server.

Scenarios

According to the documentation a Front-end / Back-end scenario comes to play when you experience or foresee experiencing performance, scalability or security issues with Microsoft Exchange:

Performance
From a performance point of view you can deploy Front-end servers to lift the burden of SSL securing your Outlook Web Access (OWA) and Outlook Mobile Access (OMA), POP3 and IMAP from your Back-end server. Blocking Unsolicited Bulk E-mail (UBE or Spam) at the Front-End might speed up your Back-end to Outlook clients connected to the Back-end server.
Scalability
From a scalability point of view you can use the configuration to make a neat Network Load Balanced (NLB) cluster of Front-end servers. Don't use Clustering Services though to scale your Front-end servers, it won't work.
Security
Despite the performance and scalability improvements you can gain from implementing a Front-end / Back-end configuration you can not use it by itself in any security scenario. Encrypting traffic with IPSec, Using the Security Configuration Wizard in Windows Server 2003 SP1 and even pinning down RPC ports will get you far, but in my opinion not far enough.

In my opinion the security design flaw in the current Front-end / Back-end configuration is you actually install a full fledged Exchange Server, which you afterwards strip of its databases and configure to relay everything to the back-end Exchange Server. It stays an Exchange Server however, which needs access to the Active Directory, DNS and other Exchange Servers. If you implement your Front-end server inside a DMZ you'll be required to open up a whole lot of UDP and TCP ports, eventually rendering your DMZ pretty useless if the box gets compromised.

"Real" Server Roles (2007)

Exchange Server 2007 introduces real server roles. As you might have read in my previous posts and other resources Exchange Server 2007 offers the following roles:

Edge Transport Server Role
Client Access Server Role
Hub Transport Server Role
Mailbox Server Role
Unified Messaging (UM) Server Role

The Edge Transport Role

The Edge Transport Role is the replacement for a Front-end server in the scalability and security scenarios. With two big distinctions:

It's safe because of the Active Directory and the Active Directory Application Mode. (now really, didn't you see that one coming?)
It only does message hygiene and routing (no Client access stuff)

You can't install the Edge Transport Server Role on a server with other Exchange Server roles and selecting the Edge Transport Server Role will make it an isolated host, with limited communications and collaboration possibilities. This means it has a minimal attack surface by default. (but you can secure it further)

Of course every Exchange Server needs access to the Active Directory. A Microsoft Exchange Server 2007 box configured with the Edge Transport Server Role is no different, but it uses a new way to communicate with the Active Directory: It utilizes Active Directory Application Mode (ADAM) to get information from the Active Directory through Edge subscriptions.

Edge Subscriptions get Active Directory information from the Hub Transport Server (on your internal network) to the Active Directory Application Mode (ADAM) database on the Edge Transport Server (in your DMZ). The component responsible for the information is the Microsoft Exchange EdgeSync service on the Hub Transport Server in the same Active Directory Site as the Edge Transport Server.

Both ends of the Edge Subscription encrypt the information based on an account in the ADAM database on the Edge Transport server. The direction of the Edge Subscription is one-way from Active Directory to Active Directory Application Mode (ADAM) and only the information that is necessary for message routing and message hygiene is being transferred:

Accepted domains
Recipients (Hashed)
Safe Senders Lists (Hashed)
Send Connectors
Hub Transport server list (for dynamic connector generation)

The Client Access Role

Since the Edge Transport Server Role is a transport role for messages you can't benefit from it to provide your colleagues with Outlook Web Access, Outlook Mobile Access, Outlook Voice Access, Outlook Everywhere or one of the other nifty "road warrior" features Exchange 2007 provides to more easily work together. In this scenario you need a Microsoft Exchange Server 2007 box with the Client Access Server Role applied to it. Although enhancements were made to Client Access Servers security the face-off between security and functionality remains. The only real way to secure it: Use Microsoft Internet Security and Acceleration (ISA) Server.

ISA Server

You can't go wrong if you shield your dong

Front-end / Back-end and separate Client Access Servers in a DMZ are not very wise choices. Unless you secure these servers with Microsoft Internet Security and Acceleration (ISA) Server. Publishing the Client Access Servers (in Exchange 2007) or the Front-End server (in Exchange 2003) from within Microsoft ISA Server is your best choice if your users really need access to their mailbox wherever they are. Check the ISA Server website for the features that protect your servers.

Conclusion

The Edge Transport Role is an Exchange Server 2007 Role that can help you secure and scale your Internet mail flow. I find it a good replacement for a Front-end server equipped with message routing and message hygiene tasks.

Microsoft Internet Security and Acceleration (ISA) Server adds the security you need to secure your Client Access Roles and Microsoft Exchange 2003 Front-end servers.

You can't place the Client Access Server Role and the Edge Transport Role on one server and you can't place Exchange 2007 Server Roles on the same server as Microsoft Internet Security and Acceleration (ISA) Server 2006. If you want to do it right, you'll need at least three servers.

Exchange Server 2007 is here! (RTM)

Sander Berkouwer — Fri, 08 Dec 2006 02:45:00 GMT

After three years of development the Microsoft Exchange team released Microsoft Exchange Server 2007, previously codenamed "E12" to manufacturing. (RTM)

More information

If you're looking for information on Microsoft Exchange Server 2007 and the way it works together with the Active Directory be sure to check out these posts:

Exchange Server 2007 and the Active Directory, Part 1
Information on Active Directory Functional Levels and their impact on the Microsoft Exchange organization, along with some basic information on the new Exchange System Manager
Exchange Server 2007 and the Active Directory, Part 2
A closer look on the new Exchange System Manager, the way to migrate from previous versions of Microsoft Exchange server to Exchange Server 2007 and of course detailed information on preparing your Active Directory schema.
Exchange Server 2007 and the Active Directory, Part 3
Detailed information on Active Directory Site aware routing in Microsoft Exchange Server 2007 and why Hub Transport and Unified Communication Servers should always accompany Mailbox servers in your site topology.
Exchange Server 2007 and the Active Directory, Part 4
A little story on the Microsoft Exchange 2007 Edge Transport Role. By using Active Directory Application Mode (ADAM) and Edge Subscriptions it securely routes and checks your messages!

Stay tuned!

Stay tuned if you want more information on Microsoft Exchange Server 2007 and the Active Directory!

Exchange Server 2007 and the Active Directory, Part 3

Sander Berkouwer — Tue, 07 Nov 2006 10:42:00 GMT

After preparing your Active Directory you're ready to install Microsoft Exchange Server 2007 to bring the new Microsoft Exchange features to your enterprise environment. There are however a few things you need to take into account when you plan Microsoft Exchange Server 2007 Roles in your Active Directory.

As you might have picked up somewhere Microsoft Exchange Server 2007 doesn't utilize Routing Groups and Administrative Groups like Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003 did: Microsoft Exchange Server 2007 maps to Active Directory Sites for it's routing configuration.

I'll discuss the way Microsoft Exchange Server 2007 interacts with Active Directory Sites for routing from two points of view:

Newly deployed Microsoft Exchange 2007 Organization (new deployments);
Microsoft Exchange Server 2007 in a previous Microsoft Exchange Organization (coexistence).

New deployments

No more routing groups

What Microsoft Exchange Server 2007 basically does is that it maps a Routing Group to a group of TCP/IP-based subnets connected by fast and reliable connections, which is what Microsoft in Active Directory terms considers to be an Active Directory Site. Furthermore in Active Directory world Sites are used to logically represent the physical network topology, to route replication traffic efficiently and to route queries and authentication requests.

To make use of Active Directory Sites topology for Exchange routing makes perfect sense, doesn't it?

Microsoft conducted a survey to understand the use of Routing Groups and learned that when organizations used Routing Groups they mapped to Active Directory Sites most of the time. Instead of boring you with tediously setting up connectors Microsoft Exchange Server 2007 does the work for you when you deploy a new Microsoft Exchange 2007 Organization!

Not ideal for everyone

Of course not everyone wants to map it's Microsoft Exchange Organization directly to Active Directory Sites, so there's a way to change the default behavior a little bit. But not in the Graphical User Interface! (GUI) The guys from the Exchange team must have known we're real men, so they put the real Active Directory connector fiddling stuff in the commandlets. (the Graphical User Interface is for women only, right Paul?)

Something else that might have lead to the cmdlets-only strategy is the fact that you won't be changing Active Directory site links every day. Why clutter the new Microsoft Exchange Management Console with it?

The Hub Transport Role

The Hub Transport role is responsible for all internal mail flow so message routing in Microsoft Exchange 2007 Organizations is performed by servers equipped with the Hub Transport Role. All Microsoft Exchange 2007 roles are Active Directory site-ware, so servers look into Active Directory to lookup other Microsoft Exchange roles.

A Microsoft Exchange Server 2007 box with the Hub Transport Role (a "Hub Transport Server") will deliver messages to a Microsoft Exchange Server 2007 box with the Mailbox Role (a "Mailbox Server") within it's Active Directory Site or it relays the message to the Hub Transport Server in the Active Directory Site for the Mailbox Server on which the recipient mailbox resides.

If there are no Hub Transport Servers in the same Active Directory site as a Mailbox server, mail can't flow to that Mailbox server. The same is true for the Unified Messaging role, which also needs a Hub Transport Server in the same Active Directory Site.

Coexistence

When you have Microsoft Exchange 2000 Servers and Microsoft Exchange Server 2003 running next to your Microsoft Exchange Server 2007 however you will see a hardcoded routing group, but it's only there for transition and coexistency purposes. If you want to know why the routing and administrative groups are formatted the way they are, check this blogpost by Ross TenEyk.

The Hub Transport Role

The Hub Transport role is responsible for all internal mail flow. This role is similar to the bridgehead server in an Exchange 2000/2003 organization. In fact it originally was called the Bridgehead Role until it was changed.

When the first Exchange 2007 server is installed in an existing Exchange organization, you are prompted to select a bridgehead server in the existing organization with which to establish the initial routing group connector. Exchange 2007 only uses routing group connectors when it communicates with Exchange 2003 or Exchange 2000 servers in the same Exchange organization.

Exchange Routing Group (DWBGZMFD01QNBJR)

All Exchange 2007 servers are automatically put in a single routing group that is called Exchange Routing Group (DWBGZMFD01QNBJR). The initial routing group connector is assigned a cost of 1. The Hub Transport Server that you installed and the Exchange 2003 or 2000 bridgehead server that you selected are set as the source and target servers. Permissions are granted to the bridgehead server to send e-mail to and receive e-mail from Exchange 2007 Hub Transport servers.

Transitioning

Scott Landry of the Microsoft Exchange team made an excellent explanation on the teams blog on coexistence between previous versions of Microsoft Exchange Server and Microsoft Exchange Server 2007 and how to make the transition to Microsoft Exchange Server 2007 without any hick-ups. If you want to know more about the routing groups and need some pictures to understand the whole story I suggest you check it out!

Set-AdSite and Set-AdSiteLink

In Microsoft Exchange Server 2007, computers that have the Hub Transport server role installed use Active Directory sites and the costs that are assigned to the Active Directory IP site links to determine the least cost routing path from each Hub Transport server in the organization to every other Hub Transport server in the organization. After the least cost routing path is determined, the source Hub Transport servers relay messages to the target Hub Transport servers. By default, the Hub Transport servers that are located in Active Directory sites along the path between the source server and the target server do not process or relay the messages in any way.

Partners in crime

The Set-AdSite and Set-AdSiteLink cmdlets are the tools to change the way your Microsoft Exchange 2007 servers with the Hub Transport Role function.

You can use Set-AdSite to make an Active Directory Site act as a hub site. Hub Transport Servers in an Active Directory Hub Site will process messages when they flow through the Active Directory site. This allows for new routing rules, journalling options, etc. Set-AdSiteLink can be used to configure an Exchange-specific cost to the Active Directory IP site link.

Conclusion

In regards to routing your Microsoft Exchange Server 2007 boxes will always use Active Directory Sites. Routing is performed by Microsoft Exchange Server 2007 Hub Transport Servers. You need to place a Hub Transport Server in every Active Directory Site where you have a Microsoft Exchange Server 2007 Mailbox Server or a Microsoft Exchange Server 2007 Unified Messaging Server. You can change the default routing behavior of your Hub Transport Servers by using the Set-AdSite and Set-AdSiteLink cmdlets.

Exchange Server 2007 and the Active Directory, Part 2

Sander Berkouwer — Mon, 02 Oct 2006 20:26:00 GMT

Microsoft Exchange Server 2007 is bound to shake up the Active Directory world as we know it. After my first post on the soon to come Exchange Server and the Active Directory I've been playing around for 2 months with it and attended a couple of seminars on the subject.

Now we know that there probably won't be any more beta or release candidate versions of Microsoft Exchange Server 2007 we can basically line out the feature set and how it interacts with the product we've come to love and cherish as the Active Directory.

In this part I'll look at the ways of administering your Exchange servers, the ways you can migrate from previous versions to Microsoft Exchange server 2007 and the steps you have to perform to prepare your Active Directory for Microsoft Exchange Server 2007.

Administering Exchange Server 2007

In part 1 we saw that a lot of Exchange related administration tasks were moved from the Active Directory Users and Computers MMC Snap-In (dsa.msc) to the new and improved Exchange System Manager and Powershell. (The last step in every Exchange related wizard even shows you the performed Powershell command and the result it gave back)

The Microsoft Exchange Team Blog has a great post by Evan Dodds that shows you how to perform the following tasks:

Creating a new mailbox;
Modifying properties on a mailbox;
Configuring 'Exchange features' on a mailbox;
Moving a mailbox;
Checking for or changing email addresses on a mailbox or mail-enabled object.

That's right! In Microsoft Exchange Server 2007 you will be performing these tasks in the new Microsoft Exchange Management Console. In my opinion the screenshots that accompany the post show an interface that resembles the tabs within an Active Directory Users and Computers MMC snap-in (dsa.msc) on a box that has the Microsoft Exchange System Manager installed, so your learning curve won't be a very steep one.

If you appreciate virtual labs Microsoft has one on this subject ready for you to explore!

The big benefit however comes when Microsoft Exchange Server 2007 gets implemented in a large environment where the persons in the IT department have different roles and responsibilities. Microsoft Exchange Server 2007 more easily lets you make Exchange-only administrators. If you want to take it one step further it even enables you to make these kind of task pads (which we know from delegating control in our Active Directories) for people you suspect might be able to do 'smart things'...

Migrating to Exchange Server 2007

There are a couple of complicating issues that you have to take into account when you migrate from older platforms and older versions of Microsoft Exchange to Microsoft Exchange Server 2007:

The Domain Controller that is the Schema Master must be running Microsoft Windows Server 2003 SP1 or above;
You must have at least one global catalog server in every Active Directory directory service site where you plan to install Exchange 2007; (These global catalog servers must be running Windows Server 2003 SP1 or above)
For all domains in the Active Directory forest where you will install Exchange 2007 or that will host Exchange 2007 recipients, the Active Directory domain functional level must be Windows 2000 Server native or higher;
The minimum forest functional level for each forest with Exchange must be Windows Server 2003;
Your existing Exchange organization must be running in native mode;
The production server where you want to install Microsoft Exchange Server 2007 on, must be equipped with a x64 architecture-based processor that supports Intel Extended Memory 64 Technology (Intel EM64T) or supports the AMD64 platform; (Intel Itanium IA64 processors are not supported)

These system requirements reveal a couple of conclusions:

You can't perform an in-place upgrade of a Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003 to Microsoft Exchange server 2007;
You can't directly migrate from Microsoft Exchange 5.5 Server to Microsoft Exchange Server 2007; (your Exchange organization can't be native, you'll first have to upgrade to Microsoft Windows 2000 and Microsoft Exchange Server 2000 or above)
You can't directly migrate a Microsoft Windows Small Business Server 2000 to a Microsoft Windows Server with Microsoft Exchange Server 2007; (Small Business Server doesn't allow FSMO roles to be transferred, you'll have to upgrade to Microsoft Windows Small Business Server 2003, Microsoft Windows Small Business Server 2003 R2 or migrate to a combination of Microsoft Windows Server 2003 and Microsoft Exchange Server 2003 first)

This is also covered on Microsoft TechNet's section on Microsoft Exchange Server 2007 and illustrated with a table of migration scenarios:

This is when it hit me: companies have been implementing Microsoft Windows 2000 Server based Domain Controllers with Microsoft Exchange 2000 Server right on top of it for years. Calculations showed your customer it was cheaper to use one Microsoft Windows 2000 Server with Microsoft Exchange 2000 than Microsoft Windows 2000 Small Business Server since they had more than 30 users or devices, right? These will be hard to migrate:

You can't migrate directly since you can't raise your forest functional level when still using a Microsoft Windows 2000 Domain Controller. I recommend you not to demote the Windows-based Domain Controller either after you installed your new (Windows Server 2003) Domain Controller. The issues you'll be facing are more than just a hand full...
You can't migrate directly since you can't upgrade to Microsoft Windows Server 2003. Microsoft Exchange Server 2000 only runs on Microsoft Windows 2000 Servers, remember.

Preparing your Active Directory

When implementing Microsoft Exchange Server 2003 in your Active Directory you had to perform an setup /ForestPrep and setup /DomainPrep. With Microsoft Exchange Server 2007 things get a little more complicating since you now have to perform four steps:

setup /PrepareLegacyExchangePermissions
setup /PrepareSchema
setup /PrepareAD
setup /PrepareDomain or setup /PrepareAllDomains

The last two steps bear a certain resemblance with the ForestPrep and DomainPrep command, where the first two are definitely new. Here's what they do:

PrepareLegacyExchangePermissions

The setup /PrepareLegacyExchangePermissions command must be run if you have any servers running Microsoft Exchange Server 2003 or Microsoft Exchange 2000 Server and you must run it logged in as a member of the Enterprise Admins group.

Essentially, you must run the setup /PrepareLegacyExchangePermissions command so that the Exchange 2003 or Exchange 2000 Recipient Update Service functions correctly after you update the Active Directory schema for Exchange 2007, because of the new Exchange-Information property set. Here's a detailed description of the changes made by setup /PrepareLegacyExchangePermissions.

If you're about to run the PrepareSchema step you might skip this step, because the setup /PrepareSchema command can do it for you. If you add a new domain to your forest and you want to install Exchange Server 2003 or Exchange 2000 Server in this domain, or if users in this domain will log on to mailboxes on Exchange Server 2003 or Exchange 2000 Server servers in other domains, you must run setup /PrepareLegacyExchangePermissions again after you run Exchange Server 2003 or Exchange 2000 Server DomainPrep.

PrepareSchema

The setup /PrepareSchema command performs the Schema Updates needed by Microsoft Exchange Server 2007. Here's a list of all the changes made by this command in a vanilla Active Directory schema. Of course you can extract more information from the ldf files that are used by the setup program. You must run at is a member of the Enterprise Admins and as a member of the Schema Admins group and you must run this command on a computer that is in the same domain and the same Active Directory site as the schema master.

PrepareAD

The setup /PrepareAD command configures global Exchange objects in Active Directory, creates the Exchange Universal Security Groups (Exchange Organization Administrators, Exchange Recipient Administrators, Exchange View-Only Administrators, Exchange Servers and Exchange2003Interop) in the root domain, and prepares the current domain.

You have to be a member of the Enterprise Admins group to successfully perform this command. If you have existing Exchange Server 2003 servers you also have to be a member of the Exchange Organization Administrators group.

If you haven't performed the PrepareSchema step the PrepareAD command can make these changes. When your also performing the PrepareAD command with an account that is a member of the Schema Admins group is can perform the PrepareLegacyExchangePermissions command as well.

PrepareDomain

The setup /PrepareDomain, setup /PrepareDomain:Domainname and setup /PrepareAllDomains commands all prepare domains other than the domain where your Schema Master is located. The difference between the commands is the scope in which they operate. You have to be a member of the Enterprise Admins group or you must be a member of the Domain Admins group in any domain that you will prepare.

Conclusion

The system requirements for Microsoft Exchange Server 2007 prohibit you from performing an in-place upgrade of existing Exchange servers. There is also no direct upgrade path to it for servers running Microsoft Exchange Server 5.5 or Microsoft Windows Small Business Server 2000. Companies with Microsoft Exchange 2000 Server on Microsoft Windows 2000 Domain Controllers face an overcomplicated migration scenario.

There are four steps to prepare your Active Directory for Microsoft Exchange Server 2007. In a simple Active Directory configuration (where you only have one domain in one forest) you only have to perform the setup /PrepareAD command and perform it with an account that is member of the Enterprise Admins and the Schema Admins group. (assuming members of the Enterprise Admins group are also members of the Domain Admins group, which is default)

Interesting links to visit

A First Look at the New Exchange 2007 System Management Console
The new Exchange 2007 Management Console overview
Exchange Server 2007 recipient management one-liners
Microsoft Exchange Server 2007 Home on Microsoft TechNet
Upgrading to Microsoft Exchange 2007
Microsoft Exchange Server 2007 System Requirements
Microsoft Exchange Server 2007 Active Directory Schema Updates
How to Run Exchange Server 2003 ForestPrep
How to Run Exchange Server 2003 DomainPrep
Exchange Server 2003 and Domain Controllers - A Summary

Disclaimer Beta Software

Exchange Server 2007 and the Active Directory, Part 1

Sander Berkouwer — Fri, 28 Jul 2006 12:27:00 GMT

I’ve been looking at Microsoft Exchange Server 2007 Beta 2 today and the way it interoperates with the Active Directory. It won’t come as a surprise to see that Microsoft Exchange Server 2007 still relies on the Active Directory as its directory service (like Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003) but there are a lot of differences. I’ll be looking into them.

Disclaimer

Although I’m describing my experiences with Microsoft Exchange Server 2007 Beta 2 here, it by no means implies that my findings are relevant to the Release to Manufacturing (RTM) build of Microsoft Exchange Server 2007. I am convinced however that you will find most things to apply to the final product.

Active Directory mode

Domain Functional level

The Release Notes for Microsoft Exchange Server 2007 Beta 2 tells us that you will be required to use an Active Directory in Windows 2000 Native Mode.

Active Directory Domain Functional Level set to Windows 2000 Native or greater
This domain functional level is required to support the new Exchange Servers universal group.

I installed a new box with Microsoft Windows Server 2003 and ServicePack 1 and promoted it to an Active Directory Domain Controller. I didn’t change any settings for my active directory and tried to install Microsoft Exchange Server 2007 Beta 2. It gave a nice error. While installing Microsoft Exchange Server 2007 Beta 2 it looked like I needed to upgrade my Domain functional level to Windows 2003 Native Mode before setup could continue. The obvious reason for demanding a native Active Directory domain is to enable the use of Universal groups, which are added to the Active Directory in a new Organization Unit (OU) called ‘Microsoft Exchange Security’. Click here for a screenshot.

Paranoid as I am (or at least Paul thinks I am ) I immediately began doubting the possible migration scenario’s for Microsoft Exchange Server 2000 in Microsoft Windows 2000 Active Directory domains with Microsoft Windows 2000 Server Domain Controllers. Surely this doesn’t mean we’ll have to install a new Microsoft Windows Server 2003 Domain Controller, demote all Microsoft Windows 2000 Server Domain Controllers and then install Microsoft Exchange Server 2007 servers and migrate mailboxes? It sure does, just read along…

Schema Master must be Microsoft Windows Server 2003 or Microsoft Windows Server 2003 Service Pack 1
The server that holds the Schema Master Flexible Single Master Operation (FSMO) role needs to have Windows Server 2003 or Windows Server 2003 with Service Pack 1 installed.

Forest functional level

Nowhere to be found in the release notes for Microsoft Exchange Server 2007, but certainly responsible for the error I received when I installed Microsoft Exchange server 2007 on my Microsoft Windows Server R2 box is the requirement for the forest functional level to be "Windows Server 2003". You can find it however in the Planning Checklist in the Microsoft Exchange Server 2007 section of TechNet:

If you have a resource forest, or multiple forests that share an Exchange 2007 organization, then a trust relationship is required. If your topology includes multiple forests that contain Exchange 2007, or if your implementation requires a forest-to-forest trust between forests containing Exchange 2007, the minimum Active Directory forest functional level for each forest must be Windows Server 2003. For more information about raising the Active Directory forest functional level, see Raise the forest functional level

Raising the forest functional level to Microsoft Windows 2003 prohibits you from having or placing Microsoft Windows NT4 or Microsoft Windows 2000 Domain Controllers, but also brings you a couple of advantages that Microsoft Exchange Server 2007 might benefit from.

Exchange Organization mode

Your Exchange Organization (which is stored in Active Directory) will have to be native too.

Exchange Organization Operation mode set to Native Mode
The Exchange Operation mode for the organization must be Native Mode.

When I first read it I found it cryptic. The reason for this is when you install a new Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003 it automatically created an Exchange Organization in compatible mode. Apparently when you install Microsoft Exchange Server 2007 Beta 2 it automatically creates a Native Mode Exchange Organization, but I couldn’t find any way of determining the Exchange Organization operation mode from within the new Microsoft Exchange Management Console.

I downloaded the updated Support Tools for Microsoft Windows Server 2003 and fired up adsiedit.msc to look for this within the Active Directory. I found it in the properties of the Exchange Organization. I made a screenshot of it and you can find it here.

After reading the Release Notes I didn’t expect anything else.

When upgrading the Microsoft Exchange Organization from mixed mode to native mode an administrator gains a few extras like the ability to create query-based distribution groups and InetOrgPerson objects, but also some routing group and administration group functions and the ability to rename the Exchange organization itself.

Because Microsoft states that Microsoft Exchange 5.5 servers and Microsoft Exchange 2007 do not coexist it is only obvious that the native mode / mixed mode stuff is being dropped, effectively dropping any remaining Microsoft Exchange 5.5 backward compatibility.

Active Directory Users and Computers

I’ve always been very relaxed with the way you could administer most Microsoft Exchange settings for users within the Active Directory Users and Computers MMC Snap-in (dsa.msc) but while reading the release notes and enjoying a nice basket of Ben & Jerry’s ice-cream I stumbled upon the next phrase:

Active Directory Users and Computers should not be used to created Exchange 2007 objects
If the Exchange System Manager is installed, Active Directory Users and Computers will allow you create mailboxes on Exchange 2007 servers. However, this action is not supported. Mailboxes created in this way will be treated as “Legacy” (Exchange 2003 or Exchange 2000) mailboxes, even though they are on an Exchange 2007 server. Exchange 2007 has no recipient update service to update user attributes. Users created in Active Directory Users and Computers would not be fully configured unless there was an Exchange Server 2003 server or Exchange 2000 Server server in the organization that had a recipient update service configured to configure the newly created mailbox.

I read this little piece of text twice before I understand what was meant: Microsoft wants us not to use the Active Directory Users and Computers MMC Snap-in (dsa.msc) with Microsoft Exchange Server 2007 Beta 2, and perhaps even in the final build of Microsoft Exchange Server 2007… I wondered how I should make new mailboxes for users, how I could make resource mailboxes and such so I fired up the new Exchange Management Console and behold: there are action panes all over the right side of the console to make all kinds of new Microsoft Exchange objects, like ‘New Address list…’ (under ‘Mailbox’ in ‘Organization Configuration’), ‘New Mailbox…’ (under ‘Mailbox’ in ‘Recipient Configuration’), ‘New Distribution Group’ and ‘New Dynamic Distribution Group…’ (under ‘Distribution Group’ in ‘Recipient Configuration’) and a ‘New Mail contact…’ (under ‘Mail Contact’ in ‘Recipient Configuration’)

When I started the ‘New Mailbox…’ wizard from within ‘Mailbox’ in ‘Recipient Configuration’ I found that from there I could make new mailboxes. In 4 different flavours:

User Mailbox
Room Mailbox
Equipment Mailbox
Linked Mailbox

Click here to see the awesome new interface in action.

This is more of a choice and a better choice compared to the Active Directory Users and Computers MMC Snap-in (dsa.msc). Before you start to this really cool wizard is the reason Microsoft wants you to leave the Active Directory Users and Computers MMC Snap-in (dsa.msc) I think you’ll have to look at the piece of text from the Release Notes I added earlier. The reason is the new way Microsoft Exchange updates Exchange objects.

When you make a new mailbox you can choose to make a mailbox for an existing Active Directory account or a new Active Directory account. (see it for yourself here) When you choose the latter a new Active Directory user object is created in the ‘Users’ Organizational Unit (OU) within the Active Directory. Perhaps this is where the Windows Server 2003 Native mode kicks in again… it allows us to change the default container where accounts are created by using tools like redirusr.exe and redircomp.exe.

Concluding

Microsoft Exchange Server 2007 changes the way you administrator Microsoft Exchange objects within the Active Directory. Get ready by preparing your Active Directory by eliminating Microsoft Windows NT4 Server and Microsoft Windows 2000 Server Domain Controllers and raising your functional levels.

Microsoft offers Office 2007 with huge rebates.

Sander Berkouwer — Fri, 23 Jun 2006 15:13:00 GMT

I recently visited a customer, where the IT manager had second thoughts about an offer he received from his current IT partner and Microsoft.

First I’ll let you in on the specific situation of this company. Because of some poor decision-making in the past the company needed extra licenses for Microsoft Office and some Microsoft Exchange Client Access Licenses. (CAL’s) We all know the drill: Buy Microsoft Office 2003 now, buy it with Software Assurance so your customer will be granted Microsoft Office 2007 when it becomes available and they won’t have to worry about getting support from Microsoft when push comes to shove. We’re talking about 197 licenses here, just so you can get a little idea on the costs involved. However, his current IT partner, a Microsoft Certified Gold Partner and Microsoft made him an offer they said he couldn’t refuse: 60% off and Microsoft Office 2007 licenses!

This sounds like a great offer: Microsoft gives you a piece of software that you can use beyond the year 2013 and has a radical new interface that makes your people do so much more in the same time and share their documents with even more people. As the IT manager you will be the hero of the Office for decades to come and people at your office will have confidence in you as their new CEO. Start looking for that €80.000+ car! Off course this IT manager wasn’t that stupid so he asked what he had to do to get this rebate and the answer was surprisingly simple: Join the Microsoft Office System 2007 Rapid Development Program. What this means is this customer was asked to implement Microsoft Exchange Server 2007 Beta 2 (out in a few weeks) as their primary e-mail solution and implement Microsoft Office 2007 Beta 2 on workstations for which they wanted to buy the additional Microsoft Office licenses.

I heard about the Rapid Development Program, but I didn’t know any company that actually got it offered or even did these kinds of implementation. Neither did this customer and I’ll tell you why: It simply isn’t worth it.

I’ll look into some of the specific areas of attention to explain this:

Support

Microsoft promised this customer additional support when they would participate in the Rapid Development Program. My guess is Microsoft promises additional support to all participants and it’s just a matter of luck. It might be that Microsoft Office 2007 is just a new Graphical User Interface for underlying code that still exists since Microsoft Office for Windows 95, but it might just be a total bottom up rewrite. (this could explain the years of development)

I think participants of the program get a nice contract from Microsoft support explaining the term ‘best effort’. This means Microsoft might be able to find a solution (or workaround) for your problem fast or they might never find a solution.

Feature completeness

Microsoft tells us their beta products are feature complete. What they’re telling us is that all the possible features for the new product are in the beta product. What they’re not telling us is that some features won’t make it into even the most featured versions of the Release to Manufacturing (RTM) versions of the product. For example: In my Beta 1 version of Microsoft Office 12 I found a feature that I can use to save my documents as PDF files. Microsoft recently announced that this specific feature will most likely not be part of the Microsoft Office 2007 product family.

To make it even worse: Most of our customers didn’t purchase Software Assurance and therefore won’t be eligible for most enterprise editions of Microsoft products. This for instance is true for Microsoft Windows Vista where bitlocker will only be part of the Enterprise version.

Performance

Microsoft beta products contain debug code, that make it a much less performing product version than Release Candidate (RC) or Release to Manufacturing (RTM) versions of the product. Although Microsoft will give you extra support they just won’t be able to fix serious performance problems you might experience.

Migration

Migrating customers from Microsoft Exchange 5.5 Server to Microsoft Exchange Server 2007 might be tricky. Although I haven’t come around to testing it yet my guess is that Microsoft won’t be supporting a direct scenario for migration because extended support ended January 10, 2006 (originally December 31, 2005) and Microsoft already offers 33% off when you upgrade your existing Microsoft Exchange 5.5 Server licenses to Microsoft Exchange Server 2003. This might mean that the migration team has to manually extract mailboxes to PST files (which are the source of all evil, as we all know) and import them all into our new Exchange database. Bye bye simple migration scenario and bye bye Single Instance Storage.

Upgrading the product (with interim versions)

I don’t know if you ever looked at the way you upgrade your Microsoft beta products to Release Candidate (RC) or Release to Manufacturing (RTM) versions but it usually implies uninstalling the previous product and installing the new version. I’m a very reasonable person but I want to be able to sleep at night: I’m not going to do this by using Group Policy Objects. (GPO’s) and I’m even considering not doing this by using the network. I don’t know if you looked at the installed size of Microsoft Office on your computer, but we’re talking hundreds of megabytes here. Systems Management Services (SMS) Server might be a solution, but your customer will have to invest on licenses. Upgrading your network might even be necessary, but let’s not even go there… Manually upgrading two hundred workstations by uninstalling and installing Microsoft Office seems time consuming to me and not even remotely ‘least administrative effort’.

3^rd party tools and add-ons

The main problem with beta products is the features that you still don’t get but still need.Companies like McAfee, Symantec, CA and GFi all make add-on products for Microsoft Exchange Server that extend the functionality by adding antivirus, antispam, backup, disclaimer and regulatory compliance features. These companies can’t offer solutions for Microsoft Exchange 2007 yet! With a bit of luck you can get a beta version or can make a readily available version work by manually editing a thousand registry keys, but can you rely on that?

Microsoft support will be helpful of course. They will tell your customer they can use Microsoft Antigen for Microsoft Exchange and use the next generation Intelligent Message Filter (IMF) with specific settings, but do they also tell you how much these licenses are going to cost you before you find the problem?

Compatibility

Microsoft Office 2007 introduces a new fileformat, based on XML. This allows for more interoperability (when Microsoft gets it to be ISO certified, that is) but might also mean you’ll experience compatibility problems with macro’s that are currently in use. For example for communicating with that IBM AS/400 box no one with mortal wages understands these days.

Conclusion

When it sounds to good to be true, it usually is.

My guess is that my customer will spend as much money on (un)installing Microsoft Office and add-on licenses (for Microsoft products mostly) as they get rebate within the Rapid Development Program. I’m not even including loss of productivity here….

Besides: when you’re not planning on using the workstations and servers after the expiry date of Microsoft Office 2003 (currently December 31, 2013) and Microsoft Exchange Server 2003 (currently September 30, 2013) who needs new versions of these Microsoft products anyway.

Visibility Mode	Value
List Child Access mode (default)	0
List Object Access mode	1

The things that are better left unspoken : Microsoft Exchange Server

Pictures of the NGN Tablet Day

Further reading

Active Directory Visibility Modes

About HMC

About DS-Heuristics

Active Directory Visibility Modes

Changing the Visibility Mode

Concluding

Related posts

Further reading

Exchange (2003) System Manager for Vista

ESM for Windows Vista

Prerequisites

Notes

Concluding

Further reading

Exchange Server 2007 SP 1 is here

New in Service Pack 1

Patches

Features

Adjustments

Performance

Deployment

Server Core implications

Concluding

Further Reading

Exchange Server 2007 and the Active Directory, Part 5

Before AutoDiscovery

Better together

How it works

Server-side

Domain Naming System (DNS) or Active Directory Lookup

The Autodiscover Virtual Server

Managing AutoDiscovery Services

Conclusion

Further reading

Disclaimer Beta Software

Deploying Exchange Server 2007

Deployment Scenarios

Deploying a Simple Exchange Server 2007 Organization

Deploying a Standard Exchange Server 2007 Organization

Deploying a Large Exchange Server 2007 Organization

Deploying a Complex Exchange Server 2007 Organization

Concluding

Exchange Server 2007 and the Active Directory, part 4

Front-ends and Back-ends (2000-2003)

Scenarios

"Real" Server Roles (2007)

The Edge Transport Role

The Client Access Role

ISA Server

Conclusion

Further reading

Disclaimer Beta Software

Exchange Server 2007 is here! (RTM)

More information

Stay tuned!

Exchange Server 2007 and the Active Directory, Part 3

New deployments

No more routing groups

Not ideal for everyone

The Hub Transport Role

Coexistence

The Hub Transport Role

Exchange Routing Group (DWBGZMFD01QNBJR)

Transitioning

Set-AdSite and Set-AdSiteLink

Partners in crime

Conclusion

Further Reading

Disclaimer Beta Software

Exchange Server 2007 and the Active Directory, Part 2

Administering Exchange Server 2007

Migrating to Exchange Server 2007

Preparing your Active Directory

PrepareLegacyExchangePermissions

PrepareSchema

PrepareAD

PrepareDomain

3^rd party tools and add-ons