Exchange 2010 SP2: Not the headline release that SP1 was


As part of their announcements at TechEd, Microsoft revealed the worst secret in the Exchange world and told us that they’re working on Exchange 2010 SP2. The software is still in a restricted beta and won’t be available for some time yet, but the outline of the new features is solid enough for Microsoft to announce that they include:

  • Outlook Web App (OWA) Mini: A browse-only version of OWA designed for low bandwidth and resolution devices. Based on the existing Exchange 2010 SP1 OWA infrastructure, this feature provides a simple text based interface to navigate the user’s mailbox and access to the global address list from a plurality of mobile devices.
  • Cross-Site Silent Redirection for Outlook Web App: With Service Pack 2, you will have the ability to enable silent redirection when CAS must redirect an OWA request to CAS infrastructure located in another Active Directory site.  Silent redirection can also provide a single sign-on experience when Forms-Based Authentication is used.
  • Hybrid Configuration Wizard: Organizations can choose to deploy a hybrid scenario where some mailboxes are on-premises and some are in Exchange Online with Microsoft Office 365. Hybrid deployments may be needed for migrations taking place over weeks, months or indefinite timeframes. This wizard helps simplify the configuration of Exchange sharing features, like: calendar and free/busy sharing, secure mailflow, mailbox moves, as well as online archive.
  • Address Book Policies: Allows organizations to segment their address books into smaller scoped subsets of users providing a more refined user experience than the previous manual configuration approach. We also blogged about this new feature recently in GAL Segmentation, Exchange Server 2010 and Address Book Policies.
  • Customer Requested Fixes: All fixes contained within update rollups released prior to Service Pack 2 will also be contained within SP2. Details of our regular Exchange 2010 release rhythm can be found in Exchange 2010 Servicing.

Compared to the full bag of tricks that arrived in Exchange 2010 SP1, SP2 is somewhat of a damp squib and there’s a horrible suspicion that the development group might have its attention more fixed on making Exchange work efficiently as a cloud platform rather than keeping on-premises customers happy. This unworthy suspicion will be confirmed or refuted when Microsoft announces the set of features that it will include in the next major release of Exchange but a nagging concern is creeping into my sub-consciousness now.

On a more positive note, Address Book Policies (ABPs), aka GAL segmentation or the ability to serve up different LDAP-based views of a directory to different sets of users within the same Exchange organization, is the big new feature in the list. Although it is a worthy advance that is well executed and will mean a lot to the organizations that need to deploy these policies, ABPs won’t have the same fundamental impact on Exchange that some of the SP1 features have had. Compare the banal ordinariness of ABPs to SP1 advances such as the completion of retention policies and tags, the introduction of block mode replication for DAGs, and a refreshed Outlook Web App (OWA) client and a certain sense of disappointment might wash over those who expect more in a service pack.

However, service packs are not intended to be new product releases and Exchange 2010 SP1 set a new benchmark in terms of the new features and functionality that it included. In fact, there’s so much in SP1 that it is a very different product in some respects to the original release. So much so that it simply confirmed all of the hoary old advice that no sane administrator ever deployed the first edition of a new Microsoft server product. Always wait for the first service pack went the refrain and that proved correct for Exchange 2010.

Don’t get me wrong. There are other worthy improvements in Exchange 2010 SP2 that will be welcome to many and it’s always good to be able to install a release that represents the current state of the art. The change to make cross-site redirection for OWA more automatic by removing the need for users to navigate through multiple sign-on screens following a site transition and end up connecting to a CAS server in the “wrong” Active Directory site is good progress. I think it also indicates the importance that Microsoft assigns to making native in-product high availability work as seamlessly as possible.

Good news for the folks who plan to operate hybrid deployments of on-premises and cloud Exchange servers is the introduction of a wizard that eliminates many of the steps now required to configure seamless interoperability between the two sets of servers. The word is that the wizard takes care of some 40 of the 46 separate operations that administrators have to perform today and I imagine that this will remove a lot of frustration on the part of administrators who are tasked with the need to connect on-premises Exchange servers to Office 365.

I’m not sure if the reintroduction of Outlook Mobile App (OMA) will be more successful than it was in the past but someone must have been lobbying for its inclusion. I hear that simplified web browser interfaces to email are important in some markets (Japan has been mentioned in this respect), so maybe that’s where the impact of OMA will be felt.

You won’t be able to install Exchange 2010 SP2 until Microsoft releases the code to the world sometime later this year. You can start to prepare for SP2 by making your Active Directory administrators (that might even be you) aware that a schema update is necessary to support the new ABP objects and properties plus to extend mailbox properties so that Exchange can stamp ABPs on them.

Schema updates are often seen as a “tremendously difficult thing” but I suspect that this reputation was earned a long time ago when Active Directory replication was often handicapped by flaky network links and slow servers. In addition, early Active Directory deployments tended to over-complicate things (the benefit of hindsight!) by having too many domains. It therefore took careful planning to make sure that all domain controllers in the forest were updated in a reasonable time. We’ve become smarter over time, Active Directory replication has improved, network links are more capable, servers are faster, and schema updates are easier to perform, if not to schedule. In any case, you won’t be able to deploy Exchange 2010 SP2 without first updating the schema so now’s a good time to include the update in your operations plan for late 2011.

ABPs deserve more in-depth coverage so I’ll cover them in a future post. Until then…

– Tony

Posted in Exchange, Exchange 2010 | Tagged , | 7 Comments

Updated virtualization guidelines for Exchange 2010


On May 16, Microsoft took advantage of the start of TechEd North America (the marketing folks always like to have news to reveal at major conferences) to make a significant announcement about virtualization support for Exchange 2010. The two biggest and most welcome changes are outlined as follows:

As of today, the following support scenarios are being updated, for Exchange 2010 SP1, and later:

  • The Unified Messaging (UM) server role is supported in a virtualized environment. [if running Exchange 2010 SP1 – Exchange 2010 RTM is not supported]
  • Combining Exchange 2010 high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers, is now supported.”

The fact that UM servers are now supported in a virtualized environment is good but hardly earth-shattering, simply because UM remains well behind the other server roles when it comes to prioritization for deployment. In addition, having sufficient CPU to process inbound voicemail (to generate voicemail previews, for instance) has always been the traditional concern about virtualizing the UM role. This concern still exists if you are in a situation where a high volume of voicemail  must be processed. The normal rule of thumb is that a second of voicemail takes a second of CPU core to process so it’s relatively easy to figure out whether sufficient CPU power can be made available to deal with the expected volume of voicemail. According to Microsoft at TechEd, a 4 vCPU server with 16GB of memory can handle 40 incoming calls, so that’s another figure to keep in mind.

Despite some caution on my part, virtualization support for UM servers is a welcome advance as it lifts another barrier that might stop customers trying out Exchange UM. It’s worth noting here that new features in Exchange 2010 UM make it worth another look if you’ve passed on it before. Voicemail preview and MP3 codec support make it much easier to access voicemail on the run and there are many other tweaks over what was delivered in Exchange 2007.

Of course, voicemail preview only works if you run one of the seven languages that UM supports. Quite logically, Microsoft only adds languages when it is confident enough that sufficient data is available to allow UM to do a reasonably accurate job of transcribing voicemail to text or understanding human prompts. I’m not all that annoyed that Irish-English (en-ie) isn’t supported yet as there are many strange and wonderful words and phrases that we use in conversation here that are not found elsewhere.

Getting back to virtualization, the fact that “The updated support guidance applies to any hardware virtualization vendor participating in the Windows Server Virtualization Validation Program (SVVP)” means that both VMware and Hyper-V are supported, which is more good news, and Microsoft has released an updated white paper to provide advice and guidance about how best to deploy Exchange 2010 on Hyper-V running on Windows 2008 R2. No doubt VMware will have their own take on the subject in the near future.

Of course, the big news in the announcement is that DAGs are supported when they are layered upon the high availability features enabled in a virtualized platform. The previous advice was to avoid clashes between the high availability features of Exchange 2010 and those provided by the virtualized platform. In other words, you didn’t want to get into a situation where Active Manager attempted to do a failover of a database or complete server and clashed with some servers that were being moved around by the underlying platform.

I think that it will take time (and probably some failures in production scenarios) before the magic formula for co-existence between Exchange 2010 DAGs and the various hypervisors emerge. In the interim, the best advice is to keep designs as simple as possible and then test, test, and test again before you deploy any configuration into production.

– Tony

Posted in Exchange, Exchange 2010 | Tagged , , , | 3 Comments

Managing Office 365 with the one true shell


Exchange administrators have known since the release of Exchange 2007 that only wimps seek the soft comfort of the GUI-rich Exchange Management Console (EMC) when they attempt to manage servers, mailboxes, or other objects. Exchange Online, part of Office 365, doesn’t provide EMC as a management option. It’s possible to connect EMC to an Exchange organization running as part of Office 365, but not as well documented, so we won’t discuss it here… maybe in a future post.

The focus for Office 365 management is all web-based so instead of EMC, you get to use the splendor of the Exchange Control Panel (ECP). In fact, one of the obvious inconsistencies of Office 365 is the differences in web-based management that pertains across SharePoint Online, Lync Online, and Exchange Online. For example, why should I have to navigate through Outlook Web App (OWA) to access ECP and manage Exchange Online options instead of being able to go direct from the Office 365 Admin screen? I guess this is evidence of Office 365 being somewhat of a work in progress at the moment as Microsoft integrates interfaces generated by three different engineering groups into hopefully what will eventually be a cohesive whole. But that’s a story for another day.

As an administration interface ECP is OK. In fact, for an Exchange on-premises deployment you find that some management tasks only appear through ECP and not EMC. Amongst the options that are unique to ECP are discovery reports, audit reports, ActiveSync device rules, and multi-mailbox discovery searches, all of which are new features that appear for the first time in Exchange 2010. On the other hand, some other new Exchange 2010 features don’t show up in ECP, such as anything to do with Database Availability Groups (DAGs) or mailbox creation.

Why are we in the situation where management options show up in one interface and not the other and how does Microsoft select which interface to use to reveal a new management option? I think the selection comes down to a simple guiding principle: if an option needs to be exposed to Exchange Online administrators, it should appear in ECP. If not, EMC is the target. Think about it – Exchange Online administrators couldn’t care less about databases and the other components of a DAG because Microsoft takes care of all of that high-availability stuff behind the scenes. On the other hand, Exchange Online administrators care very much about mailboxes and their properties, so the ability to manage these objects is revealed through ECP.

Note however that the ability to create new mailboxes is not revealed in ECP. This feature existed in ECP until relatively late in the beta releases of Exchange 2010 but disappeared for the final release. As shown below, Office 365 allows administrators to manage users and mailboxes through the overall Office 365 Admin screen.

Office 365 Admin

ECP is perfectly functional in its own way in terms of day-to-day management of Exchange Online but it’s a tad restrictive too because you’re limited to the decisions made by the development group as to what options appear in the “slabs” that compose the ECP interface. Just like a deployment of on-premises Exchange 2010, ECP knows what “slabs” to reveal by reference to role-based access control (RBAC). Users that have been assigned more powerful roles (such as Organization Management for on-premises deployments or TenantAdmins or Organization Management for Exchange Online) see more options revealed by ECP than less privileged users. Such is the way of the world.

In any case, to return to the overall theme of this post, ECP will eventually frustrate you because some of the things you might want to do to manage an Exchange Online deployment are simply unavailable. It’s at this point that you decide that the shell is the only way to get work done. It’s also when you might realize that the change made in Exchange 2010 to move from a focus on local PowerShell to channel all PowerShell commands through remote connections is far more strategically important to the long-term technical direction of Exchange. In a nutshell, while remote PowerShell might seem like overkill and a royal pain in the rear end for an on-premises deployment, it is the fundamental building block for management in the cloud – or for hybrid deployments where some objects run on-premises and some exist in the cloud.

Creating a remote PowerShell connection to Exchange Online is much easier than you might realize, especially if you do it from a Windows 7 workstation where all of the necessary components (like PowerShell 2.0) are available. The sequence required to connect is broadly similar to the way that you’d hand-construct a session to an on-premises deployment of Exchange 2010. Of course, few people bother to do this because Microsoft provides the warm comfort of a script to make the connection and build the necessary environment for administrators. That script is run when you select the “Exchange Management Shell” (EMS) option, which is how administrators generally run remote PowerShell for Exchange 2010.

We want control so we’ll do everything manually!  First, run Windows PowerShell (running as an Administrator seems to be best). Once PowerShell loads, we run the Get-Credential cmdlet to collect the credentials that will allow us to connect to Exchange Online. You’ll need to provide the SMTP address and password for an administrator for an Exchange Online domain to be able to do anything useful.

$Cred = Get-Credential

Next, we create a new remote PowerShell session. There are two differences in the command that we use when compared to an on-premises deployment. First, the connection point is https://ps.outlook.com/powershell rather than the FQDN of an Exchange 2010 server that supports your mailboxes. You don’t know what servers your objects are stored on in Exchange Online, (and logically, the names of these servers are not revealed outside Microsoft) so the target is a general-purpose connection point that services all incoming requests for PowerShell sessions. The other magic is provided by the -AllowRedirection parameter. This instructs Exchange that it should redirect the connection to a server that can access data for your Exchange Online domain. In the screen below, you can see the name of the server to which I’ve been redirected.

$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic -AllowRedirection

Once we have a connection, we can import the connection into our session. The second command here is simply to satisfy my curiosity and to know just how many cmdlets are available to me during my remote PowerShell session with Exchange Online.

$NewSess = Import-PSSession $s
$NewSess.ExportedFunctions.Count

You can make things easier on yourself by creating a function containing these commands and inserting it into your personal PowerShell profile. This will allow you to simply execute one function to connect to Office 365 each time you use PowerShell, which seems like a good thing to do. For more information, see Brian Desmond’s blog.

As you might recall, part of the initialization processing that occurs when you connect to Exchange 2010 or Exchange Online is an RBAC evaluation to determine exactly what cmdlets (and indeed, what parameters for cmdlets), a user is allowed to run. My recent experience with Exchange Online shows that I generally am allowed to run 216 cmdlets. This is far fewer than is the case for an Exchange 2010 on-premises administrator who can expect to be able to run over 600 cmdlets, which means that you can’t assume that any script code developed to run against an on-premises deployment of either Exchange 2007 or Exchange 2010 will run against Exchange Online. Not only is it likely that some cmdlets will be missing, you can run into difficulties if you attempt to run code that expects to access system data such as the registry. Obviously, the cloud doesn’t have a registry!

On the other hand, the whole point of using Exchange Online is to allow you to devolve a large percentage of day-to-day mundane work to Microsoft so there’s no need for you to access cmdlets such as Get-ExchangeServer, Get-ClientAccessServer, or New-SendConnector that deal with issues that you will never concern yourself with, such as interrogating server information or creating new connectors.

Connecting to Office 365 with remote PowerShell

At this point, we have a functioning remote PowerShell session that is ready to run any of the cmdlets that we are permitted. Standard stuff that focuses on mailbox management such as Get-Mailbox or Get-MailboxStatistics work and it’s possible to do things like extract mailbox move reports. It’s also possible to manage mailbox settings with Set-Mailbox. For example, to set Single Item Recovery for a mailbox (not an option revealed by ECP), you run:

Set-Mailbox -id TRedmond -SingleItemRecoveryEnabled $True

Note that Set-Mailbox is one of the cmdlets that Exchange regards as “potentially destructive” and therefore comes under the control of the PowerShellMaxDestructiveCmdlets setting applied through a client throttling policy. The setting used in Office 365 seems to be more restrictive than in on-premises Exchange and if you attempt to run commands that change a lot of data you may be throttled back. For example, depending on the number of mailboxes you have, if you use Get-Mailbox to form a collection of all mailboxes and then use Set-Mailbox to change a setting, Exchange might tell you that it needs to delay things a little as it processes each mailbox. I guess the idea is to give you the chance to realize that you might be making a mistake (as if that would happen) and hit CRTL-Z before too much damage was done…

The properties returned by Get-Mailbox are quite interesting as they cast a light into how Exchange is deployed within Office 365. For example, I see that Microsoft keep archive mailboxes in the same database as primary mailboxes – probably following the KISS principle and keeping the deployment as simple as possible. You can also see some new cmdlets that Microsoft activates for cloud deployments. For instance, Get-MailboxPlan reveals the various mailbox plans that are available to apply to mailboxes. Think of a mailbox plan as a template of properties to apply to a mailbox to control how it functions. It would be nice if mailbox plans were also available for on-premises deployments.

So good so far and we’ve found out some esoteric but interesting information. Some additional poking around with PowerShell will reveal the boundaries that Microsoft has set on tenant administrators and determine just what is possible in terms of changing the environment to meet business requirements. For example, in the sequence of commands shown below, I list the set of retention policy tags defined by Exchange Online and the tags used by the default policy that Exchange Online automatically applies to all mailboxes. Then I create a new retention policy based on the set of tags plus an additional personal tag (Keep 10,000 days) and assign the new retention policy to my mailbox.

Adding a new retention policy to Exchange Online

New retention policy tags aren’t exposed in clients until the Managed Folder Assistant (MFA) processes a mailbox, so we force MFA to run to make the magic happen:

Start-ManagedFolderAssistant -Identity TRedmond

The next time we start a client (in this case OWA), we see the new personal tag show up.

New 10,000 retention tag appears in OWA

Interestingly, unlike with an on-premises deployment, some of the properties that can usually be set with Set-Mailbox are inaccessible with Exchange Online. For example, you can’t set a retention comment.

Amongst the other things that I have done so far with PowerShell is to create a discovery search mailbox (for some reason, Office 365 had not done this for my domain) and manipulate role assignments to assign my account the Discovery Management role so that I could perform searches. PowerShell allows an administrator great latitude in terms of getting real work done but it’s also got to be said that you can also do damage by running a naked PowerShell command if you don’t know what you are doing. The solution is to read up on the commands that you’re interested in (see the book reference below) and to test commands if at all possible before you run them for real.

Of course, if Office 365 is your production environment, you’ll want to maintain a separate instance of an Exchange 2010 on-premises test environment for this purpose. You can easily create such an environment with a couple of virtualized servers. Although it’s true that the two environments won’t be the same, you’ll learn a lot by playing with PowerShell in your testbed and so reduce the potential for making mistakes when you manipulate live data through the shell.

The conclusion therefore is that PowerShell is a very real weapon in the armory of the Exchange 2010 administrator whether you run on-premises or in the cloud. Sure, you can do less to manage Exchange in the cloud, but isn’t that the reason that you signed the contract with Microsoft?

– Tony

Note: If you need to manage both on-premises and cloud data in a single PowerShell session, you might like to consider applying a prefix to each connection so that you can identify the data you’re dealing with. See this post for more information.

Learn more about topics such as remote PowerShell (chapter 3), RBAC (chapter 4), and ECP (chapter 5) in Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk. You can also purchase the book in a Kindle edition.

Posted in Exchange 2010, Office 365 | Tagged , , , , , , , , , , | 4 Comments

Excluding disclaimers for encrypted or signed messages


In a recent post, I described the basic approach to building an Exchange 2010 transport rule to build corporate disclaimers containing Active Directory data and formatted nicely with HTML that are then appended to all outgoing messages. The approach works well in most instances, but there are situations when you don’t want Exchange to go anywhere near an outgoing message.

Encrypted or signed messages are an obvious example. These messages only remain trusted as long as their integrity remains intact. It’s obvious that if a transport rule was to process a signed or encrypted message to append a disclaimer, its integrity would be pretty compromised. For this reason, Exchange doesn’t attempt to open signed or encrypted messages when it processes transport rules that might append some information (see TechNet for more information). Instead, these messages are wrapped in another message to which Exchange can apply the disclaimer and the message passes through to its destination, where the recipient sees a message containing the disclaimer and an attachment containing the original message.

In most cases, this is fine and the recipient is happy that they’ve received the content that they expect without any question that the email system has examined or interfered with the contents in any way. However, in some cases, you might want the original message to be passed through with no attempt being made by Exchange to apply the disclaimer.

As outlined in Exchange 2010 Help, the Exchange developers clearly anticipated this need because they provide the ExceptIfMessageTypeMatches parameter to allow transport rules to exclude certain types of messages. The supported types are:

• OOF
• AutoAccept
• AutoForward
• Encrypted
• Calendaring
• PermissionControlled
• Voicemail
• RSS
• Signed
• ApprovalRequest
• ReadReceipt

There’s some gold to be mined here because “Signed” and “Encrypted” are two of the supported message types. We can therefore go ahead and take a transport rule that applies a corporate disclaimer and amend it slightly to exclude the message type that we need to pass through without being processed. For example, to exclude digitally-signed messages, we would run the Set-TransportRule cmdlet as follows:

Set-TransportRule –Id “Disclaimer” –ExceptIfMessageTypeMatches "Signed"

Once the cmdlet runs, the transport system will begin to exclude signed messages from its processing and they will be passed intact through to their destination. You can also accomplish the same goal by selecting the transport rule with EMC and running the wizard to modify the rule. You need to move through the wizard to the fourth screen, which deals with exceptions. Scroll down to find the exception for message types, click on the check box and then select “Signed” or “Encrypted” from the list.

Using EMC to select a message type as an exception

So good so far, unless you want the rule to exclude both signed and encrypted messages from applying disclaimers. At this point you discover that the predicates used for conditions and exceptions in Exchange transport rules usually take just one value. In this case, it would be wonderful if you could run a command like:

Set-TransportRule –Id “Disclaimer” –ExceptIfMessageTypeMatches "Signed, Encrypted"

But this isn’t supported – at least, not in the current builds of Exchange 2010. Rats!

However, the flexibility of transport rules comes to our rescue again because we can deploy rules to “search and mark” signed and encrypted messages and then exclude the marked messages in our disclaimer rule. Remember that Exchange processes transport rules in order of priority so as long as our “search and mark” rules fire before the corporate disclaimer rule, all should be well.

Message classifications are useful here (actually, this is one of the few places that I have found them to be useful). First, we create a new message classification that we can use to mark messages through transport rules:

New-MessageClassification -Name 'Do Not Process' -DisplayName 'Do Not Process'              -SenderDescription 'Used by a transport rule - not for human beings'

Next, we create two new transport rules. The first rule looks for encrypted messages and does nothing except stamp these messages with our “Do Not Process” classification. The second rule does much the same thing for signed messages. After the transport system processes messages with these rules, any message that is signed or encrypted (or both) should be stamped with the “Do Not Process” classification.

New-TransportRule -Name 'Select Encrypted messages' -Comments 'This rule selects encrypted messages and stamps them with the Do Not Process classification' -Priority '1' -Enabled $True -FromScope 'InOrganization' -MessageTypeMatches 'Encrypted' -ApplyClassification 'Default\Do not process'

New-TransportRule -Name 'Select Digitally signed messages' -Comments 'This rule selects digitally signed messages and stamps them with the Do Not Process classification' -Priority '2’ -Enabled $True -FromScope 'InOrganization' -MessageTypeMatches 'Signed'                -ApplyClassification 'Default\Do not process'

We can then update the rule that applies corporate disclaimers with a new exception specified in the ExceptIfHasClassification parameter that looks for the classification that is applied to signed and encrypted messages. These messages are promptly excluded so they pass through without a disclaimer being applied. Note that the identity of the message classification includes “Default\” as you can have different language values for message classifications within an Exchange organization.

Set-TransportRule -Identity 'Corporate disclaimer' -Name 'Corporate disclaimer' -Comments 'This rule applies the approved corporate disclaimer text to all outgoing messages.'       -ExceptIfHasClassification 'Default\Do not process' -Priority '3'

So there you are… we hit a limitation in Exchange transport rule processing and overcame it using transport rules and accomplished our goal without burning up too many brain cells or time. I’m sure the more inventive members of the Exchange community will have other ideas as to how to best solve this problem, so I am all ears to hear their suggestions!

– Tony

Want more information about all the weird and wonderful things you can do with Exchange 2010 Transport Rules? Read all about them in chapter 16 of my most recent book, Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk. The book is also available in a Kindle edition.

Posted in Exchange, Exchange 2010 | Tagged , , , , , | 7 Comments

On email disclaimers


The April 7 article “Spare us the email yada-yada” published in The Economist provoked some consideration of how email disclaimers have evolved to a point where they have become one of the “minor nuisances of modern office life”, mostly because the information inserted in the disclaimer is designed to make the legal department happy and is largely ignored by anyone else.

The first disclaimers were text-only and were applied in the form of autosignatures or text automatically inserted by an email client when messages were created. With modern clients, autosignatures can be extremely complex and graphic-rich, such as the example of an executive who cut and pasted a picture of a newly-arrived baby into his autosignature and inflicted a couple of extra megabytes of loving graphics onto all his correspondents.

The problem with autosignatures is that they are personal. Administrators may ask users to follow a set format for their autosignature and include whatever text is deemed appropriate by the company, but there’s no good way of checking that every single user has done the right thing short of asking them to send you a message. Even then, users can change their autosignature at any time and are prone to follow the latest habit, whether this is to insert the company’s logo or some other graphic that does nothing whatsoever except waste a vast amount of disk space on email servers and keep disk salespeople happy. I’ve never quite worked out why people insist on inserting company logos into their autosignatures because invariably the vast bulk of their messages are internal and everyone knows that the sender works for the company and what the company logo is like… Maybe it creates a warm feeling of belonging. I don’t know…

The difficulty of implementing standard autosignatures or having users include the text deemed necessary by regulatory or other requirements leads us to system-applied disclaimers. This feature has been with us for quite a while. Early versions of Exchange used third-party products or home-grown “event sinks” to insert text into outgoing messages. Things got a lot easier and much cheaper with the introduction of transport rules in Exchange 2007 as you can define a rule to append text to every outgoing message. Some limitations exist in Exchange 2007 such as the plain text nature of the appended disclaimers, but the fact that you could define and apply a transport rule to do the job in about three minutes was a huge advance when compared to the torturous and costly effort required to write an event sink for Exchange 2000 or Exchange 2003.

Today, Exchange 2010 allows great flexibility in building transport rules that create the potential for administrators to have the transport system automatically stamp all outgoing messages with nicely formatted disclaimer text and so avoid the need for users to create individual autosignatures with their email client. Here’s an example that I discuss in chapter 16 of my Microsoft Exchange Server 2010 Inside Out book.

New-TransportRule -Identity 'Company disclaimer' -Name 'Company disclaimer' -Comments 'This transport rule applies the approved company disclaimer to every outgoing message' –Priority ‘0’ -Enabled $true -SentToScope 'NotInOrganization'  -ApplyHtmlDisclaimerLocation 'Append' -ApplyHtmlDisclaimerText
'<h4 style="font-family:verdana">Contoso Corporation</h4>
<p style="font-family:verdana; font-size:70%;color:green">
This message is the property of <b>Contoso Corporation.</b> If you receive this message in error, please delete it <u>immediately</u> and inform us at 827-1176 about its delivery.
<p style="font-family:Arial; font-size:80%; color:blue">
<i>%%FirstName%% %%LastName%%</i>
<p style="font-family:Arial; font-size:70%; color:red">
Phone: %%PhoneNumber%%
<p style="font-family:Arial; font-size:70%; color:red">
Email: %%Email%%'
-ApplyHtmlDisclaimerFallbackAction 'Wrap'
-ExceptIfSubjectOrBodyContainsWords "This message is the property of Contoso Corporation"

A number of important points are illustrated here that serve to demonstrate just how feasible it is to replace the vast bulk of user-specified autosignatures with system-generated text. First, Exchange 2010 allows you to include data extracted from Active Directory, so we’ve specified instructions to extract commonly-included attributes such as the user name, phone number, and email address in the transport rule (these items are prefixed and terminated with %%). You can find the full set of Active Directory attributes that are available for use in transport rules in TechNet.

Second, while Exchange 2007 allows a rule to append simple disclaimer text, Exchange 2010 can do a much nicer job by instructing the transport rule to use HTML formatting. Unfortunately, EMC doesn’t include an HTML editor, so you can normally expect a few trial-and-error attempts before you will input the HTML code 100% correctly, but once it’s done, you end up with the ability to produce some very nice results. If you want, you can also include an image file in the disclaimer by including a reference such as the one shown below. Ideally, such an image file will be as small as possible (2KB seems like a good target) so as to avoid the dreaded “message size swelling with embedded graphics” syndrome.

<IMG src="http://webserver.contoso.com/images/contosocompanylogo.gif">

The final flourish is performed with the instruction contained in the ExceptIfSubjectOrBodyContainsWords parameter, where we specify that Exchange shouldn’t add the disclaimer text if the message already contains it. This avoids the situation where a message thread contains multiple repeats of disclaimer information that obscures the really important information contained in the messages.

Of course, rules that generate disclaimers like this depend on accurate population of Active Directory. In other words, if the data can’t be extracted from Active Directory, you’ll end up with blanks as Exchange won’t guess what the information should be.

The bottom line is that while disclaimers are an annoyance of office life, the litigious nature of modern society means that we won’t be able to revert to the simpler life that existed for early email systems. Then again, we didn’t have to deal with so much spam or virus outbreaks then either, so maybe all these things are advances. What’s important is that transport rules offer a real solution to the problem that can be very quickly implemented to apply the necessary disclaimer text and allow us all to move on to the next item in our work list.

– Tony

Posted in Exchange, Exchange 2010, Technology | Tagged , , , | 3 Comments

San Diego Maestro


We’ve just wrapped up the Exchange 2010 Maestro seminar in San Diego and everyone is making their way home after a pretty exhausting three days. Wednesday was particularly tough with an early start at 8am finishing up with a presentation from Binary Tree, one of our sponsors, at 6:10pm before drinks at 6:30pm. Binary Tree spoke about their new E2E Complete product, which helps administrators automate migrations to Exchange 2010. They have plans to upgrade the product to handle migrations to Office 365, which seems like a pretty good idea to me.

HP, another of our sponsors, brought in an HP E5000 messaging system for attendees to examine. The solidity of the equipment impressed as did the concept of an appliance that delivered a “DAG in a box” but was also flexible enough to be customized to meet specific requirements. After all, the E5000 is a pair of Exchange 2010 servers that can be modified from the basic layout once the systems are installed. For example, while HP has configured the various models of the E5000 to handle different mailbox loads, a fair amount of headroom has been included as well, so it’s reasonable to assume that you could load more mailboxes on the servers, especially if they used intermittently.

Dawn view over San Diego from Manchester Hyatt

San Diego is a nice place to hold a training event. People like coming here because the weather is usually good, there’s a wide range of hotels to stay in, and there’s the famous Gaslight District to chill in after training shuts down every night. Our seminar was held in the Manchester Hyatt, a place that I’d stayed at several times before for other events. The view from my room on the 31st floor was pretty special, even if Thursday’s was somewhat spoilt by a sea fog that rolled over the Naval Air Station and San Diego airport.

The hotel did a good job of keeping us all happy as the facilities were excellent (lunches on a sunny terrace were fully appreciated), the AV worked, and the wireless network stayed up for the entire event. While some of these points may seem petty, you’d be surprised just how many seemingly top-class hotels can’t provide reliable AV and network services for events like this, so it was good to be at a place that could.

Due to unforeseen circumstances, Paul Robichaux had to return home early and left us on Wednesday afternoon. The value of having a strong team of MVPs staffing the seminar was proven when Brian Desmond stepped in to deliver Paul’s session on the Exchange 2010 transport system. Of course, Brian isn’t an Exchange MVP as he earned his MVP status as an Active Directory guru, but he knows his stuff about Exchange too. He’s also a wizard with Office when it comes to creating labels for spices in the kitchen, as evident in this post.

Once again we had problems keeping to our schedule. All of our noble aspirations that we would observe the time slots laid down in the agenda went out the window, mostly because our audience was so engaged that they came up with many interesting questions that simply had to be investigated and explained! It’s hard for the audience to sit through some 21 hours of presentation over three days and also participate in some workshops so we’ll have to review the agenda again before we present our next event in Greenwich, CT in October.

Friday sees me taking United to Chicago to join up with the Aer Lingus flight to Dublin. It’s at times like this when I regret the loss of the direct flights from San Francisco and LAX to Dublin that Aer Lingus ceased in 2009. It seems like Ireland could do with a direct connection to the US west coast, but what do I know about airline scheduling and flight planning?

– Tony

Posted in Exchange 2010, Training | Tagged , | Leave a comment

Rugby, weapons, and conferences


Lots has been happening over the past two weeks with trips to Las Vegas to speak at “The Experts Conference” (TEC), Flayosc (south of France) for some vacation, and England for rugby. It’s time to consider some of the incidents encountered along the way.

I landed in Las Vegas late on the Saturday before TEC. The direct BA flight from LHR is recommended as it takes off from London at a reasonable time (16:25) and gets to Vegas at 18:25. The upshot is that you have a fair chance of avoiding jet lag because you get to your hotel at a time when it seems appropriate to go to bed. Of course, activity is also a good way to tame the jet lag blues and that’s what I did on Sunday when I had the chance of engaging in a pursuit that is totally legal in Nevada but totally illegal in Ireland. Five of us set off in a van to go into the desert, whereupon one of our party, a very skilled and experienced weapons specialist, revealed the arsenal carried in the car. Four automatic rifles and a collection of handguns, not to mention enough ammunition to take on a small South American country, were unveiled for our pleasure.

Enjoying myself with an AR-15

I fully accept that many people have problems with sporting use of weapons and believe that no one outside the law enforcement agencies and military should have access to rifles and handguns. This is certainly a rational position and it’s the one that exists in many parts of the world. However, Nevada is a western state where the right to bear arms is cherished. Accordingly, we had great fun blasting at a range of targets, including some that exploded in a rather gratifying way when they were hit. While I have fired various shotguns, rifles, and pistols several times before, I am by no means experienced with arms and it was good to have someone who could instruct us in the right way to handle and load the weapons. All in all, it was an unusual and effective way of eliminating jet lag.

TEC is a small conference that prides itself in the deep level of technical content in its sessions, especially anything to do with Active Directory (TEC originated as a conference dedicated to all aspects of directory technology). My assessment is that some of the sessions were indeed very good and worthwhile but like all conferences, there were others that were pretty awful with speakers who may have had command of their content but couldn’t communicate its worth or import to the audience. On the upside, Microsoft put in a very strong effort and the Exchange development group delivered a number of very good sessions. I also noted that the conference was run very well with a lot of attention to detail, which is always good to see. The conference hotel (Red Rock Resort) was also good, especially because it was well away from the infamous Las Vegas strip.

A massive egg laid on the side of a hill in Tourtour

After returning from Las Vegas, we spent last week in the south of France for the Easter break. The weather was a tad disappointing at times with some terrific thunderstorms but we managed to get a reasonable amount of work done in the house and garden to prepare for the summer, including the purchase of the all-important tables and chairs for the terrasse. We also had the chance to visit a “Fête de Pâques” (Easter celebration) in Tourtour (Var), one of the prettiest villages in France (or so the sign said). The whole village had clearly put a great deal of effort into preparing for the day and had decorated the entire place with eggs, chickens, and other Easter-like paraphernalia, including what seemed to be a massive fried egg that was deposited on the side of a hill (above). The movie buffs will know that Tourtour features in the “Day of the Jackal” where the assassin meets the countess at the “Bastide de Tourtour“, an excellent hotel if anyone is looking for a place to stay in Provence.

Easter chicken in Tourtour

As usual, the Aer Lingus flight to Nice from Dublin passed reasonably easily. The only problem we encountered was with car rental at Citer (National in other countries), who trotted out a claim that the new electronic fuel gauges on Citroen cars are faulty when I discovered that the C4 Picasso that they provided was only 7/8 full. Citer has used this excuse three times so far with us in 2011. They then compound the problem by sneakily charging to top up the fuel after you return the car. Unlike other car hire companies, Citer check the fuel level on cars after they reach the garage to be prepared for another hire, at which time they fill the car and charge you if the tank is not brimming. Most of their competitors at Nice such as Hertz, Sixt, and Avis check the tank when you return a car to ensure that it is reasonably full. No more is said if the needle is at the top of the gauge. Citer’s pretty dubious business practice is to claim that they have had to refill the car with a small amount of fuel, after which they put through a charge on your credit card. It’s invariably less than 10 Euro and I’m sure that some people don’t even notice the charge – but I do and have fought them and got a refund each time it’s happened. The solution is for Citer to fill their cars properly before they go out, to use the same check-in practices to validate tank contents as their competitors, and to stop this silly practice of slipping small charges through in the hope that their customers won’t notice.

European club rugby resumed this weekend with the semi-finals of the Heineken Cup. On Saturday, Leinster beat Toulouse 32-23 in a gripping game that I watched in the Marriott Heathrow, a typical airport hotel that served as the base for the Irish refereeing team for the second semi-final between Northampton and Perpignan. Neutral refereeing teams of (referee, two assistant referees, two touchline controllers, and the TMO) are appointed for these games. On Sunday, we set out for the soccer stadium in Milton Keynes, which is the ground that Northampton had picked for the game. It was a sell-out of around 22,500 with a reasonable scattering of Perpignan fans. Unfortunately the game didn’t go well for them and Northampton ran out comfortable 23-7 winners. A fast turnaround found on back on the road to LHR in a ultra-smelly Avis special for a late flight back to Dublin.

Tomorrow, I travel to San Diego for the first Exchange 2010 Maestro seminar of 2011, which starts on Tuesday. No doubt many good questions will be raised by the seminar participants that I can report on in future posts. Until then!

– Tony

Posted in Rugby, Technology, Travel | Tagged , , , | 2 Comments

Free Exchange 2010 Seminar in Dublin


If you’re interested in Exchange 2010 and are in Dublin on May 11, you can register for a free seminar that I will be speaking at on the topic of practical and economic issues that influence the decision to deploy on-premises or hosted Exchange 2010/Office 365.

Click here for the registration page!

– Tony

Posted in Exchange 2010 | Tagged , | Leave a comment

An ActiveSync logo compliance program: How nice!


On April 13, Microsoft announced details of their ActiveSync logo compliance program. While it’s taken me a little while to comment (other things go in the way), I think this is a good idea because it should rein in the tendency for ActiveSync to rapidly degrade to become the wild west of mobile communications interface standards. Microsoft really had to rein in the monster that they had unleashed when they launched the ActiveSync licensing program and encouraged mobile device manufacturers to adopt the standard without committing to implement a specific set of functions.

The result of Microsoft’s success in evangelizing ActiveSync over the last few years is that it has become the market-preferred synchronization protocol for mobile devices other than RIM’s Blackberry. Device manufacturers aren’t stupid and the fact that Exchange has continued to grow and taken an ever-commanding share of the corporate email market since server-based ActiveSync (EAS) first appeared in Exchange 2003 SP2 has been a huge factor in the adoption of ActiveSync. Together, the combination of easy licensing and a swelling user base means that ActiveSync has steadily reinforced its position, even if the companion Windows Mobile devices never impressed and the implementation of ActiveSync on devices such as Apple iPhones and various brands of Android devices wasn’t particularly complete. At times it seemed like some vendors implemented ActiveSync as if it was just a slightly more sophisticated version of POP3 or IMAP4 that was optimized for mobile devices and forgot that while email and calendar synchronization is important to end users, other pieces of functionality such as enabling remote wipe, enforcing password policies, and supporting AutoDiscover are really important to system administrators.

A good implementation of ActiveSync is much more than making sure that email was downloaded effectively as it arrived on a mailbox server (see this wikipedia entry to get a broad view of ActiveSync capabilities on different mobile platforms). The new compliance program seeks to address the problem by specifying 14 policies that an implementation must support before it is considered compliant.

Why is it important to implement the ActiveSync system administration features? Well, here are a few facts of system administration life:

  1. New mobile devices appear more rapidly now than they used to and this trend is going to continue.
  2. Users treat mobile devices as accessories and want to use the latest and greatest. That’s why they change phones so often.
  3. If they spend a lot of money to switch to the latest and greatest device, users are frustrated when they’re told that they can only use specified devices at work. They want to use a single device and will attempt to connect whatever device they feel like, even if policies say that only a list of approved devices are supported.

Exchange 2010 includes the ability to define and deploy ActiveSync device access rules that allow companies to implement restrictions on the devices that are allowed to connect. This is a good thing and you can get extremely granular about the device family and versions that you support (for example, only Windows 7 phones manufactured by HTC). ActiveSync policies depend on ABQ (Allow/Block/Quarantine) strings – information presented by the device to identify itself when it connects. The ActiveSync logo program requires devices to support ABQ strings to allow ActiveSync device access rules to be applied.

Exchange 2010 ActiveSync access rules are one of the pieces of functionality that are only exposed through the Exchange Control Panel (ECP) rather than the EMC console. To see the rules used in an organization, go to ECP, opt to manage the organization, go to “Phone & Voice”, and click on “ActiveSync Access”. Or you can use the EMS cmdlets such as New-ActiveSyncDeviceAccessRule to create a new rule, or Get-ActiveSyncDeviceAccessRule to view the current rules, and so on. For example:

Get-ActiveSyncDeviceAccessRule | Format-Table Name, Characteristic, QueryString, AccessLevel - AutoSize

But policies only work when devices broadcast accurate information to identify themselves and users, especially those with some influence within the organization, are willing to accept that some control is going to be exerted over the devices that they can connect to download and send email, which can of course contain valuable intellectual property that should be protected. Some companies really struggled after Apple launched the iPhone when they found that users were connecting to Exchange to access their email – and many of the users were executives! Cue another discussion about Apple’s flawed implementation of ActiveSync (see Paul’s blog for details).

While major vendors such as Apple (iPhone 3GS, iPhone 4, and iPad) and Nokia (what a surprise!) have signed up to support the new program, it’s hard to know whether the Microsoft ActiveSync logo compliance will achieve its goal. On the plus side, a standard has now been set for manufacturers, customers, and end users… and that can’t be a bad thing. After all, there’s a ton of non-compliant devices floating around today and it will take time before their useful working life expires and they are replaced, hopefully with compliant devices – assuming that a wide range of these devices are available.

Of course, time will tell just how observant device manufacturers will be. Consumers will know nothing about the purpose or meaning of the ActiveSync logo. Likely, it’ll just be another annoying sticker that has to be peeled off before a device can be used. This means that IT departments will have to do a good communications job to help users do the right thing and select compliant devices – or adopt the fist-in-your-face approach and implement stringent ActiveSync policies (if they use Exchange 2010) to block connections from anything other than compliant devices.

One curious point is that the standard to gain the ActiveSync logo doesn’t include security policies such as enforcing the requirement for devices to be encrypted or for their storage cards to be similarly protected. Omitting these policies weakens the standards because it means that devices that can store gigabytes of confidential data such as budgets and PowerPoint presentations describing company strategy can achieve compliance. Companies seeing the ActiveSync compliance logo may assume that all such devices are suitable for deployment in secure environments, or even inside corporate deployments. The security departments of large companies have torn their hair out because of the risk of information leakage from mislaid mobile devices for years and this program doesn’t help them at all.

A cynic might observe that Microsoft defined the standard to ensure that the widest possible set of devices might be certified, including their current implementation of  the Windows 7 platform, which has some acknowledged issues in that respect. Of course, that’s not the reason but a certain lingering suspicion is in the air. But there’s hope for future improvement as revealed in this statement in the Exchange team’s blog post giving their view of the announcement:

Over time, the program will evolve to require additional features and management policies

Maybe the Windows 7 developers are waiting for the new program to develop before they’ll add the ActiveSync security features to their platform? If so, while they are waiting, you can continue to deploy Windows Mobile 6.5 devices, safe in the knowledge that while this platform is now sadly outdated, it is at least part of the new compliance program and it supports a wide range of security features.

– Tony

For more information about Exchange 2010 ActiveSync device rules, see pages 626-631 of Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk. The book is also available in a Kindle edition. Other e-book formats for the book are available from the O’Reilly web site.

Posted in Exchange, Exchange 2010, Technology | Tagged , , , , | Leave a comment

Two conferences call for sessions for Fall 2011


The two conferences that cover topics of interest to Exchange, including Exchange itself, SharePoint, and Windows, have issued calls for sessions for their Fall conferences. TEC’s Fall event is in Frankfurt, Germany from 17-19 October while Fall Connections is in Las Vegas from October 31 to November 2.

The TEC call for sessions is described here. Connections looks for proposals for its conference in a slightly different manner by sending email to folks that the conference chairs believe are suitable presenters. I guess this method has the advantage of selecting from a well-defined and well-known pool but I prefer to cast a net far and wide to see who would like to volunteer for the job. With this in mind I’ve included the text sent by Connections below. If you’d like to propose a session, please send email to Jim McBee using the address JMcBee AT cta.net.

I encourage anyone who considers them to be knowledgeable about Exchange, SharePoint, or Windows (Active Directory is a primary focus of TEC) to consider submitting a session to the conference of your choice. The very best sessions are based on hard experience and contain tips and techniques that are forged in the fire of battle. Anyone can deliver a marketing-style fly-by through a set of new features and bore an audience silly, especially if that audience has paid good money to come and learn. Getting up in front of your peers and helping them to share your experience and knowledge is a wonderfully fulfilling thing to do and it can help you expand your horizons in different ways: in your career (good communications skills are always an advantage for those who want to succeed), in professional associations (Microsoft selects MVPs based on contribution to the community and presenting at major conferences is a great way of proving your contribution), or just by being part of the team who delivers great content at great conferences.

So go on – think about it – and extend yourself by submitting a session! Both conferences have deadlines for submissions so you should get your thinking caps on.

– Tony

Text of message to potential Connections speakers:

Aloha!

   The Fall 2011 Exchange Connections conference planning is well underway.   The conference will be October 31 – Nov 2 with pre-conference sessions on Sunday October 30 and Thursday November 3.  Microsoft Day will more than likely be Monday October 31.

  So, it is that time for you to put your thinking caps on and come up with some brilliant session ideas for which the Exchange and Unified Communication masses will cheer!   We are looking for a balance of about 60% Exchange content, 30%, and 10% cloud (such as Office 365). 

We don’t know exactly how many session slots are going to be available for this show yet nor do we know if we are going to have a travel budget for international travelers.  For those of you from outside the US, we want to keep you in the loop on session proposals in the event we have more international shows.  In general, speakers are expected to present at 3 sessions per conference.  Please submit to me at least 3 (if not 4 or 5) abstracts.

Please provide me at least 3 (if not 4 or 5) proposal abstracts by April 26.  Microsoft presenters: You may be asked to present on Microsoft Day in which case this deadline may not apply to you. I can put you in touch with the Microsoft Day coordinator.

Our strong preference is for you to present material that has never been used at other public conferences or events.  Connections attendees expect to come and hear material that is valuable and not a rerun from a previous event. However, we accept that there are situations when you may want to propose material that has been used elsewhere and in these circumstances we expect you to tell us why. For example, it is appropriate to propose a session for a European conference that was previously presented at US Connections. It may be appropriate to propose a session for Fall Connections that was used at Spring Connections, providing that this session was well received by the attendees. It may also be appropriate for a Microsoft presenter to present a session that was previously an internal-only Microsoft session.

Connections attendees have told us that they need some guidance as to what sessions they should attend. Please tell us who should attend your session and what they will learn by attending. It’s helpful to categorize sessions as follows:

–              Technology Overview

–              Deep dive

–              Best practices

–              Notes from the field

In no case is it appropriate to present marketing-style material at Connections. We know that there is a strong preference for material that is at the 300 level (as used at TechEd) or higher. Remember that so much information is available through TechNet, blogs, magazines, and books today that a real challenge exists to build a session that captures an audience and provides real value to attendees. Sessions that are based on hard experience, that tell people how to avoid deployment problems, and assist them to succeed in their projects are always popular and well-received. Sessions that merely go through features of new products or new versions are not. 

We are expecting high quality abstracts from you.  The abstract should be between 125 and 200 words.  Your abstract should set the attendees expectations as to the type of content, what they will learn, and who should attend.  Catchy titles are cool, but the session content is still king. Below is an example (with a not very catchy title):

EXC01: My Exchange Server is on a Fault Line (Establishing an Exchange 2010 Disaster Recovery Site)

This session describes a number of best practices from organizations that have deployed Exchange 2010 Database Availability Groups (DAGs) across multiple sites to enhance their high availability capabilities and enable immediate restoration of service if disaster strikes the primary datacenter. Establishing a disaster recovery site for Exchange 2010 is more than adding an additional Exchange server and a few mouse clicks. Through in-depth discussion of practical notes from real-life deployments, attendees will learn about disaster recovery site prerequisites, common disaster recovery scenarios, and design issues to take in to consideration when deploying a disaster recovery site. This session will also include detailed coverage of the steps necessary to switch over to the disaster recovery site and how to switch back. Exchange administrators planning to extend DAGs across multiple datacenters to provide disaster recovery capabilities should attend. A basic knowledge of Exchange 2010 and Windows Failover clustering is recommended. Exchange administrators that are planning to stretch DAGs across multiple sites will benefit from attending this session. 

Finally, if your sessions are selected, we will expect that you will help promote your sessions and the conference through your blog, your Web site, your personal Facebook, your user groups, the Conference Facebook site, or Twitter. Nothing elaborate, but at least a mention that you are speaking at Connections on topic X, Y, and Z. The Exchange Connections Facebook page can be found here:

If you have some specific ideas you would like to run by me, please feel free to forward them on.

Thanks much!

Jim McBee

Posted in Active Directory, Exchange 2010, Office 365, SharePoint 2010, Technology | Tagged , , | Leave a comment