Dave Stork's IMHO : Management

Script converting Mail-User to Mailbox-User

dmstork — Mon, 29 Apr 2013 11:57:21 GMT

Not all organizations need to have every user to be mailbox-enabled, sometimes a mail-user (also referred to as mail-enabled user) with a forwarding SMTP address to an external mailbox is enough. However, it is surely possible that the requirements over time change and the mail-enabled user does need to be mailbox-enabled, making use of the calendar or perhaps even more efficient use of Lync integration.

However, converting a mail-user isn’t just changing the RecipientType of the account. First the users needs to be mail-disabled, most importantly it then looses all the configured SMTP addresses and the forwarding address. Then the user has to be mailbox enabled and all SMTP addresses that aren’t added via an Email Address Policy have to be manually added. Optionally, one can configure the mailbox to be forwarding to the external SMTP address.

To make this process somewhat more manageable, I created a script that converts a mail-user to mailbox-user. It keeps all configured SMTP addresses, when they correspond with an accepted domain (otherwise it will be discarded). The exception is the configured External SMTP address, it is optional to keep forwarding mail.

The syntax is depicted below:

Convert-MailUser –Identity <UserIdParameter> [-KeepForwarding]

The mail user will be mail disabled without a need for confirmation. The parameter -Identity is mandatory and a string. Accepted formats are:

User Principal Name
Display Name
Distinguished Name (DN)
Domain\Account
GUID

The switch [–KeepForwarding] is optional. This switch will retain the SMTP Forwarding address from the mail-user and will add it as an ForwardingSMTPAddress, with mail being forwarded to that address and sent to the Exchange Mailbox. No additional value (like $true/$false etc.) is required.

Please note that the ForwardingSMTPAddress value does not show up in the Exchange Admin Center view at the moment (Exchange 2013RTM CU1). You will have to use the Exchange Management Shell (Get-Mailbox|fl) to check whether the Mailbox is forwarding mail to an external address.

You can download this script from the TechNet Gallery.

Note: This script has been tested on Exchange 2013 on Windows Server 2012, but will probably work on 2010 and 2007 and Windows 2008 R2. Use at your own risk and the script is provided as-is.

The UC Architects episode 14 is now available!

dmstork — Fri, 28 Dec 2012 14:33:00 GMT

Episode 14 is now available for download! It is hosted by Steve Goodman and co-hosts were John Cook, Serkan Varoglu, Johan Veldhuis and Stale Hansen.

Christmas
Exchange 2010 SP2 RU5 Version 2
Issues with the Windows Management Framework on Exchange 2010 and 2007
Lync Pilot Kit
Lync Conference 2013
Tips for early adaptors on Lync 2013
Issues with Live.edu to Office 365 migrations
What will be hot in 2013?

The newest UC Architects episode is now available from iTunes and the Zune store and via www.theucarchitects.com. Previous episodes are also available from the same locations.

Simplifying the OWA URL with Citrix Netscaler

dmstork — Mon, 24 Dec 2012 12:16:00 GMT

Next to Content Switching (which I recently wrote a post about), Citrix Netscalers can also do URL Rewrites. This enables us to simplify the OWA URL.

First, be sure the Rewriting option is enabled by going into System, then Settings and choose Configure Basic Settings. Check the tick box for Rewrite

After this, first make an Rewrite Action by going to Rewrite>Actions and add an Action. Give it a comprehensive name and set the type to REPLACE. In the Expression the following should be used:

http.REQ.URL

In the String expression for replacement text, the following value should be used:

“/owa/”

Be sure to type it in and not copy it from this blog, otherwise it could not workd correctly. The screenshot below shows the value as mentioned before. Click Create to create the Rewrite Action and click Close to close the window.

Now you can create a Rewrite Policy by going to Rewrite>Policies and then click add…

Again, give it a sensible name and be sure the Action is set to the earlier created Rewrite Action (in the screenshot below Rewrite_Action_OWA).

For the Expression, use the following:

http.REQ.URL.EW(“/”)

Again, type it and do not copy and paste. Finally, press Create and Close. This Rewrite Policy now checks for URL's which use the root path / and will replace it with /owa/.

But in order to make it happen, the policy has to be enabled somewhere. In this case I bind it to a Load Balancing Virtual Server already previously made (see this blog post). This has to be the Virtual Server which is responsible for (at least) Outlook Web Access.

Open the Virtual Server, go to the Policies Tab and press the Rewrite (request) button. Right-click in the window and choose Insert Policy. Choose the previously made Rewrite Policy as shown below:

And voila! Now every user entering https://webmail.contoso.com/ will be directed to https://webmail.contoso.com/owa/ without a fuss! And because the policy triggers only on the root, directly using /owa, or /ecp for that matter, will also work.

How about HTTP to HTTPS redirection?

That is not done via Rewrites, but there are more ways than one. Make a Load Balancing Virtual Server, listening on port 80 and as IP address the Virtual IP used for OWA. You do NOT check any services. Instead go to the Advanced Tab and in the Redirect URL enter HTTPS:// with the virtual IP used for Webmail. Press Create and close. Do remember to enable traffic over TCP port 80 towards the Netscaler, otherwise this won’t work. This is also described in the Netscaler Deployment guide and depicted in the image below:

If you are also using Content Switching, you can also make a Content Switching Virtual Server accepting traffic on port 80 and again using the OWA Virtual IP. As a target the Load Balancing Virtual Server using port 443 should be used (that can be used multiple times as a target. Description how it was made in this blog post). This is shown in the image below:

You should make duplicate Content Switching policies, as they can only be used once. The Expression however, is exactly the same as the Content Switching Policy used in the Content Switching Virtual Server using SSL.

Now every user will be directed to the correct URL, whether they use http://webmail.contoso.com, https://webmail.contoso.com/ or http://webmail.contoso.com/owa/ .

Load balancing Exchange 2010 with Citrix Netscaler using Content Switching

dmstork — Fri, 21 Dec 2012 17:45:00 GMT

Next to F5, KEMP technologies and a lot of other network load balancing vendors there’s also Citrix with it’s Netscaler brand. Especially when an environment also has Citrix servers, it could mean that well scaled Netscaler devices are present and can also be used for other purposes next to Citrix Secure Gateway access. Obviously Exchange 2010 comes to mind.

Citrix already has a very helpful Netscaler Exchange 2010 deployment guide (PDF warning). But unfortunately that guide is not always something one can implement exactly. For instance, in the guide Citrix uses an unique IP address for each separate protocol, which is not always possible if these are limited.

However, all or most Netscalers also provide Content Switching and with this you only have to use one IP but also have optimized settings for persistence/affinity and time-out for all protocols using the same TCP port (HTTPS). For some background information around persistence for Exchange 2010, check this article.

First create the services as described in the Citrix Deployment guide. You make one per physical server for each specific service, like HTTP (Load Balancing>Services>Add>):

When that is done you can create a Virtual Server for each different protocol, meaning OWA, ActiveSync, OAB, EWS etc. (Load Balancing>Virtual Servers>Add>). In this example, the OWA Service is shown with the specific Load Balancing method and persistence options (note that COOKIEINSERT requires SSL Offloading).

But instead of entering an IP address, keep it emtpy and untick the “Directly Addressable” box.

Now you have to make sure Content Switching is enabled on you Netscaler. You can do that via System>Settings>Configure Basic Settings> Enable Content Switching.

After this you can create Content Switching (CS) Policies via Content switching>Policies>Add…. For OWA I would check whether the specific hostname is requested in the HTTP request: HTTP.REQ.HOSTNAME.CONTAINS("webmail.contoso.com")

You can build it with the expression builder via Configure… button and build the expression from there.

When you’ve made the CS Policies, you can now make Content Switching servers via Content switching>Virtual Servers>Add…

Now you can add the IP address the Netscaler has to respond to. This is also the Virtual IP (VIP) address you have to point your FQDN for OWA and other protocols towards.

In the CSW field (open per default), right click and choose “Insert Policy”. A drop down menu appears (as shown above), and every available CS policy is visible. Note that a policy can only be used once.

In this case the previously made webmail.contoso.com policy is selected. Now select the target field and the different Load Balancing Virtual Servers are listed, in this case only VIP_Exchange_OWA.

Select it and choose Yes in the corresponding question box,

Now every HTTP request on IP 172.16.0.205 with FQDN webmail.contoso.com will be directed to use the Load Balancing Virtual Service which uses two Client Access Servers previously defined as valid services.

If you want to make another Load Balancing services for other protocols with other persistence timeout values, but with the same VIP, make another Contents Switching Policy and add it to the same Content Switching Virtual Server. However, you will have to point them to other Load Balancing targets, namely those with the optimal settings.

For Autodiscover use the expression:

HTTP.REQ.HOSTNAME.CONTAINS("autodiscover.contoso.com")

For ActiveSync use the expression:

HTTP.REQ.HOSTNAME.CONTAINS("webmail.contoso.com") && HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/microsoft-server-activesync")

For EWS, OAB and Outlook Anywhere you can change the ActiveSync expression with the URL Paths /ews, /oab and /rpc. If you don’t specify these specifically, they would just use the OWA Content Switching policy (as it is agnostic about the path in this case) and thus the same persistent values as those specified for OWA. I found that it is sufficient most times.

Insert every CS Policy in the CS Virtual Server, and order them in the correct sequence. Note that Netscalers checks policies with a lower priority value first and works up to higher values (first 10 and then 100). The protocols which would trigger with specific paths in it should come first, otherwise they would be triggered by our first policy and will not get the optimized load balancing rules.

In the above example you can see the generic webmail.contoso.com policy has an OWA target and a priority of 100. Subsequent policies are ActiveSync (EAS), Autodiscover and Offline Address Book (OAB) each with a corresponding target and persistence settings.

After implementation you can check whether the rules are (correctly) being used by watching the Hits column.

So with Netscaler Content Switching you are able to still optimize persistence settings per protocol and still use one Virtual IP address for each HTTPS service.

For these screenshots I’ve used the Citrix Netscaler Free trail virtual appliance which can be downloaded from www.citrix.com. Note that for some of these settings you’ll also need SSL Offloading. The specific configuration and certificate selection (in the Content Switching Virtual Server for instance) is not shown.

Managing mailbox storage with Exchange 2010, Part 3

dmstork — Tue, 18 Dec 2012 21:26:00 GMT

In the previous part one and two of this series, I’ve discussed using PSTs, Exchange Personal (on-premises) and On-line Archiving as well as third party solutions. In this last post I will discuss the use of Retention Policies and Mailbox quota’s in order to manage storage usage. As a bonus I will shortly discuss improvements in Exchange/Outlook 2013.

Retention Policies

The basic Messaging Records Management functionality behind Retention Policies isn’t actually that new. In Exchange 2000 and 2003 you could configure Recipient Policies and in Exchange 2007 you had Managed folder Content Settings.

All of them regulate the retention of mail items (and since SP2RU4 Exchange 2010 also managed calendar and tasks items) of the complete mailbox or certain specific folders within a users mailbox. You can delete it with recovery, delete it without recovery or move it to the Archive Mailbox (if the users has one). For instance, a 90 day old mail in Deleted Items or even Sent Items could have lost it’s worth and the cost of keeping it in the mailbox too high, but the user could keep forgetting to clean up or the mailbox is shared and hasn’t got a main user which keeps it manually neat and clean. As it is processed server side (on the Mailbox role), the effect is client independent.

In Exchange 2010 you can give users the option of tagging specific (sub) folders and mail items, so that these objects will have another retention than the default setting. You can allow users set No Archive/No Delete tags or increase (or lowering) the retention period of the item (via a Personal Tag). But the admin still has control on which tags are included in a Retention Policy which is in it’s turn appointed to a mailbox and default folders aren't configurable for users. However, usage of (non default) Personal Tags in a policy requires an Exchange Enterprise CAL, other cases only an Exchange Standard CAL is required.

Personally I use them for certain mailing lists, like all my LinkedIn notification mails. Their use expires quickly (because it’s just a notification, thus I've changed the folder retention period from default (never delete) to 30 days after which the mails are deleted.

A very helpful tool, which can benefit admins a lot because it lowers resources. But it is also helpful users by keeping some folders lean and mean, which reduces the risk of reaching quota limitations and it helps keeping only items that really matter.

Combined with the Personal Archive or Online Archive, an admin or an user can control when items are moved to the archive mailbox rather than just deleted.

Too bad the policies only work on retention and not on other criteria like Categories, and that it processes the whole mail item and not just the attachment for instance.

Benefits:

Admin has control and is able to give users (some) control
Actions (such as deletions) are performed automatically on the Mailbox server, no client side rules thus also valid for other clients than Outlook
Different policies with different Policy Tags can be implemented on a per mailbox basis
No added license cost for default settings, it is included in the Standard Exchange CAL
Can be combined with Archive Mailbox

Drawback:

Only on retention, no specific rules on mail items with attachments for instance.
Users need to be instructed about the admin settings in order to prevent accidental deletions
Has a bit of a learning curve
Mailboxes with customized retention polices with Personal Tags, require an Exchange Enterprise CAL

Mailbox quota’s

And last but not least, Mailbox Quota’s. These are settings on a database or mailbox level (which overrides the database setting) and entail a warning, prevent sending and ultimately prevent sending & receiving mail threshold. It is actually on of the things you use to correctly size your mailbox server role.

But how does this help you? Well, even if you have sized your server by the book, it doesn’t mean your users will adhere to your expectations and sometimes faulty clients or other reasons can overflow a mailbox. In extreme cases it could use all available disk space and cause Exchange to dismount the database. Which leads to unhappy users.

Usually I tend to configure the quotas on the database level and have several databases (maximum of five on Exchange 2010 Standard) with different quota levels. This is an easy way to make it easy on administrators or even your service desk to quickly raise someone’s quota by simply moving the mailbox to another database (which isn’t much of a problem anymore with Exchange 2010 as the mailbox is only shortly locked at the end of the move).

With Exchange standard you can have up to five databases, so you can have five different quota settings. Four if you still need a Public Folder database. I tend to call this Mailbox Quota Tiering. It is a bit more tricky to project each DB’s maximum size, so capacity management in one form or another will be important. Furthermore, you’ll need management backing for the different quota settings and a clear process for moving users from one quota tier to another.

However, if you have a Database Availability Group and several Mailbox servers this could result in an less than optimal distribution of databases. Therefore in those cases I revert to specific mailbox quota’s per mailbox, when the database default (the same on all DB’s) isn’t sufficient. Management is more cumbersome, using scripts is probably a good way to reduce this.

In my experience having a Mailbox Quota Tiering system offers you and/or management a tool for controlling quota’s and thus storage use. I’ve seen too much issues rise from suddenly imposed quota’s and/or clean up requests due to rapidly shrining free storage space. Having several quota’s also offers users an alternative than immediate cleaning, which is more service oriented. This could be even more important than the technical benefits.

Benefits

When properly sized, quota’s help preventing storage filling up due to an issue or normal growth
When using DB specific quota’s, one only needs to remember to place the mailbox in the correct DB
Having a clear quota policy in place helps prevent unpleasant surprises for users, management and admins

Drawback:

When using mailbox specific quota’s, additional administrative effort is required
It’s no guarantee storage won’t fill up, storage space monitoring is still required
You’ll need backing from management for the specific quota settings and a process in place for moving users from one tier into another

Outlook 2013

Since I planned this series of posts, Outlook 2013 has been released. One feature that could be helpful is the Sync slider or the OST slider. As Exchange 2013 raised the supported mailbox size from 25GB in Exchange 2010 to 100GB an issue can occur when the computer with Outlook 2013 in Cached mode does not have the space required to store this amount of data. Especially laptops and slates with SSD prefer speed over storage space. However, it does not manage the amount of storage needed on the Exchange server but I felt it was worth mentioning as it does have effect on local computers storage.

The OST slider (see image) is a way to limit the amount of data stored on the local drive by only downloading the last 2 or x amount of months. You can give users the control over it or configure it via Office 2013 Group Policies. When an item isn’t stored within the OST, Outlook needs a connection to the Exchange server. You could say it is comparable with the Personal Archive functionality, however you do not need an Exchange Enterprise CAL for this and you can differentiate the OST Slider settings per computer. You do need an Office 2013 license obviously.

This feature can be another approach to limit the amount of data stored locally and thus can be a competitor of the Personal Archive. Especially when you have Office licenses with Software Assurance the costs are possibly less than when you have to purchase said CAL. If needed you could combine it, but the limitations of the Personal Archive are then still present.

Benefit

Works with Exchange 2007, 2010 and 2013
User control or admin control on OST slider
Data can be stored in a single mailbox, no need for Archive

Drawback

Needs Office 2013 (with Outlook)
Only time based
Only tackles the amount of storage needed on client computers, not on the Exchange server

Overall Conclusion

Well, we discussed PSTs, Personal/Online Archive mailboxes, Third Party Archiving solutions, Retention Policies, Mailbox quota’s and the new Outlook 2013 OST Slider. As you can see there are several approaches to manage the amount of storage necessary for Exchange and Outlook. Except for perhaps PSTs (“Kill it with fire!”), there isn’t a complete answer.

As an admin and organization, you still have to decide which technology suits your needs and wants the best. It could be just one solution or a combination of some or all of them. I hope I gave you some pointers that will make it more easy to decide which is the best fit for you.

This concludes this series of blog posts on managing mailbox storage with Exchange 2010. Please note that some techniques are valid for other versions of Exchange, but my main focus was Exchange 2010.

Managing mailbox storage use in Exchange 2010, Part 1
Managing mailbox storage use in Exchange 2010, Part 2

Exchange and malware protection

dmstork — Thu, 06 Dec 2012 20:23:06 GMT

This blog post is something I intended to write for a while now, because it is a question that i get asked a lot. On which Exchange server roles do you need to install the Exchange malware protection software, be it the now no longer for sale Forefront Protection for Exchange or similar products from McAfee, Symantec or GFI and the like.

Why is this IMHO a valid question? Well, if we ignore the Microsoft recommendation to install multi-role servers (meaning the CAS, Hub Transport and Mailbox Server roles), you can take benefit of not needing to install the malware protection software on all servers when it has no or little benefit. Note that I mean Exchange malware protection, I do not mean the file-access server protection. Let's go over the specific Exchange 2007 and 2010 roles:

Client Access Server

On this server there is no mail flow and there are no databases present. In this case no malware protection is necessary or even useful. It only handles client protocols and none of them are scanned by Exchange aware solutions, that I know of.

Hub Transport Server

This server handles all mail routing. Obviously incoming external mail does need malware scanning, so when this server is directly connected to the internet and receives not previously scanned mail, I normally would install a solution on this server role. Even mail from one mailbox to another in the same organization or even the same mailbox database is transported through this role. So, if an user is mailing an infected attachment to a coworker, it should be quarantined or cleaned. Everything that is transported can or will be scanned by your malware protection on the Hub Transport server.

You could however choose to not use on-premises scanning, if you use an Exchange Edge Transport server with malware protection or if you use cloud malware protection such as Forefront Online Protection for Exchange (FOPE), recently renamed Exchange Online Protection (EOP). These vendors generally have very good cleaning ratio and it lowers the load on your administration. Another option is to use on-premises appliances that are your first entry point for SMTP traffic before entering your Exchange Organization.

Mailbox Role Server

This is a tricky one. As said, all mail transported can be scanned via the Hub Transport server. If you have such protection, you could dispense of scanning this role as most infectious malware is received via external mail. But there are cases that an infected mail could end up in a mailbox and thus the mailbox database. A user sends an infected mail to a coworker or to the outside, the recipient does not receive it as it is filtered by the Hub Transport server. However, the mail is already saved in the Sent Items folder of his/her mailbox. With an infected attachment... The same is for writing a mail with an infected attachment and save it as an draft. Again the Hub transport does not get to scan this message and the message will reside in the mailbox database, unless the user or admin deletes this manually.

The only automatic way to get rid of these malicious mails is to do a real-time or regular database scan, which costs server resources especially with real-time scanning. I do not know of any confirmed cases that an Exchange server got infected by infected mail in the mailbox database (or Public Database for that matter). Because of that I feel that it is safe to say that the computers that are at real risk are client computers (or devices). You could argue that these computers are possibly already infected, because how could it allow an infected file to be uploaded? If so, the risk of infection of the client computer is 0% as it probably already is infected. Other client computers (used by the same user with the same mailbox) should be protected by their own virus scanner (perhaps with additional protection via Network Access Protection, NAP), but if this is a risk you are not willing to take you should implement a Exchange malware protection layer on the mailbox server role. But consider that when you have protected the mail flow and all clients, this risk possibly doesn't outweigh the extra cost in resources (IOPS, Memory, software licenses etc.).

If you need as close to 100% protection, you should implement a mailbox role solution. And having said that, consider that sometimes mail does not always origin from clients or via SMTP, but a cross-forest, platform etc. migration could bypass SMTP. In this case, mail (probably) does not get filtered before it is put in your Exchange organization and the only way to filter malware is to scan the databases. You could use a pre-staging Exchange server, a dedicated Exchange server with malware protection that scans all migrated mailboxes. It would clean mail before you move mailboxes to your production environment mailbox servers, which perhaps don't have mailbox server protection. But that is added complexity.

Now note that I'm not advocating the absence of malware protection, but I did want to make an overview of choices one perhaps has to make when (financial) resources are limited or even just to clarify a bit about malware protection in Exchange 2007 & 2010. I hope it helps with your design choices.

To summarize: mail flow should always be protected on-premises or via the cloud with installation on the Hub Transport server has the best change to catch malware in most thinkable scenarios, scanning mailbox database servers is probably less effective but should be done when the highest form of security is required and the loss of resources is acceptable and incorporated in your design.

Exchange 2013 has a changed infrastructure with less roles, no VSAPI on which malware protection suites can latch on and already has a built-in malware scanning module. This is so different and new, that will probably warrant a blog post on it's own.

If you have a different opinion or flat out disagree with me, feel free to leave comments!

Using the Microsoft Connectivity Analyzer Tool

dmstork — Sat, 01 Dec 2012 15:13:00 GMT

Recently Microsoft released an updated version of the Microsoft Exchange Remote Connectivity Analyzer rebranding it as the Microsoft Remote Connectivity Analyzer as it now also can test Lync connections, next to Exchange and Office365.

Another addition is the Microsoft Connectivity Analyzer Tool, a local variant of the online tool for Exchange connections. This is a very helpful tool for internal testing and despite being in beta, it already successfully helped me correctly identifying a certificate issue before I used it in production.

As it is a local tool, it uses your local DNS and network routing. As said this is helpful for local troubleshooting as sometimes the connectivity is different from (for instance public Wi-Fi networks) than the external connection. But another effect of this that you can use it in lab and testing environments before making changes final. In my case we did not yet change external DNS A-records to point to the new Exchange 2010 datacenter, everything else was already set up for publishing. By changing my local host file I could test the new datacenter with the correct domain name as if it were in production.

I already detected an issue with the Outlook AutoDiscover process, and however the Auto configuration tool in Outlook is helpful (On Outlook Tray Icon, CTRL+Right click mouse and select “Test E-mail Auto Configuration”), it does not give detailed information on errors in the way the Remote Connectivity Tool gives. Below is an example of this test, with a successful result.

So, how do you use the tool? Go to the connectivity site and select the Client (beta) tab, depicted in the first image of this post.

It will verify Application requirements, if the tool isn’t installed yet a Security Warning appears:

You can click install if you want to install the tool. Now it will check for prerequisites. You will have to install prerequisite .Net Framework 4.5.

As I think this installation broke some .Net applications (MetroTwit) I would advise to install this on a testing computer and not on an Exchange server! That also makes it more easy to change host files and other things.

After installing .Net Framework 4.5 and rebooting your computer you can click the link on the Connectivity site again. If you are using Chrome or Firefox, you may need to install additional extensions. For Chrome (my main browser) you need to install ClickOnce for Chrome”. Firefox needs the Microsoft .Net Framework Assistant for Firefox.

After everything is set, the tool starts by using the links on the Connectivity site Client tab, ultimately the following screen popups:

For my issue, I used the “I can’t log on with Office Outlook” option and entered the account information as I would have on the site. Luckily no Captcha .

After all the tests are run, you get the result screen. You can save it as an HTML file and/or review the results of the tests.

The HTML file is an awesome addition, as you can now easily send the results to a coworker for further examination. Below is an excerpt from such an HTML file. With the same formatting as the website and the tool. Note the red square, as you can see it has a non public IP address. Proving that this tool could be invaluable for local testing of Exchange connectivity.

Thanks to this tool I discovered that the AutoDiscover process failed at a later point than I first anticipated and that the certificate is loaded but failed to validate for the AutoDiscover domain name. As it turned out there is probably an issue with this specific certificate. Something that I previously probably only would have found out if I put this certificate into production and with a broken AutoDiscover process as a consequence.

Even if the tool is beta, it already helped me prevent unnecessary service disruption!

Managing mailbox storage use in Exchange 2010, Part 2

dmstork — Thu, 29 Nov 2012 06:49:00 GMT

In the previous part (yes, I know. It’s from May… I’m very ashamed) I discussed using PSTs or the built-in Personal Archive (also referred to as Online Archive).

In this post we will discuss third party archiving solutions and Exchange Online Archiving which in this case is service part of Office 365, although you can mix it with an on premises solution. (see the possible confusion)

Third Party Archiving

As it seems, organizations had long ago issues with overflowing Exchange stores and storage. In that niche, numerous third parties like Metalogix Archive Manager, Symantec Enterprise Vault or GFI MailArchiver, filled the need. However, there are two ways at looking at archiving; storage or compliancy focused (or in between).

Third Party archiving advertise with storage management. That is indeed something they can help in and was at first their main focus, understandable as storage was expensive but email was not regarded the same importance as it is now. In my view their current best strong suit on archiving has now changed to compliancy regulations. Especially since SOX etc.. these solutions are sometimes indispensible.

Some customers automatically propose a third party archiving solution, because they have a lot of data etc. etc.. But I am skeptical the moment this happens. Exchange 2010 isn't 2003 anymore and reasons to implements such a solution in the past could be no longer valid. To summarize, Archiving solutions may have started with storage maintenance but due to changing external factors and architectural changes in Exchange it’s focus has shifted towards compliancy. An important thing to realize, as it could affect your choice of storage management.

Most solutions require one dedicated server for the server application and storage of archived items. For metadata most times a SQL server is required. This could mean that instead of data reduction one is just shifting data from one place to another. That could be enough due to storage tiering etc.., but the extra overhead can not be discounted. Yes, if you have a DAG with multiple copies, this would reduce that amount. But you loose the same amount of redundancy with it, unless you take action for the archive and thus still have to account for at least twice the amount of storage the archive. Even if you only need compliancy, you will have to address these issues (some compliancy regulations specify a need to keep all mails for at least several years).

Furthermore, you have to take extra care backing up the archiving servers keeping it in sync. Nowadays this seems to be handled a lot better, but these solution always add an extra complexity to you environment. You have to decide whether this is worth it.

And last: these solutions are not for free and there are always additional licensing costs, most of the time per mailbox and or per specific feature. Also, don’t forget the Windows Server licenses and in some cases Microsoft SQL server licenses.

Benefits:

Flexible rules regarding archiving and compliancy (time, size based, only attachments etc. etc.)
Most of the times also compliancy built-in
Data stored outside the Exchange environment, sometimes with Single Instance Storage limiting even more storage space

Drawbacks:

Still need storage for archived mail, although less when there is no need for redundancy
Most of the time additional servers needed (for instance: File Storage, meta database, the service itself) and thus higher complexity
Additional administrative effort for maintaining archiving solution
Additional licensing fees (most solutions work per mailbox)

Third party archiving solutions can be helpful and are more flexible with archiving rules than Exchange own rules which are only based on the age of the item, but consider the investment you have to make especially if you don’t need it for compliancy reasons.

Exchange Online Archiving

The Exchange Online Archiving is basically the same as the Exchange Local Online Archive functionality mentioned in part 1 of this series. The difference here is that the Archive Mailbox is now located in Exchange Online. For this to work you do have to setup DirSync and Federation Services, just as an Hybrid Exchange environment. In fact, it is an hybrid environment but you don’t have to put main mailboxes in Exchange Online.

The upside is that you pretty much don't have to worry about archive storage because you don't host it. Availability, capacity etc. are all cared for by Office 365/Microsoft. Users don't even have to notice that their archive is not on-premises. You do have to pay a fee per mailbox, but the costs are predictable and it could very well be cheaper per GB than having it on you own storage solution.

You do need to account for extra administrative effort due to the Federation and DirSync services, although probably less than an Exchange server. If they are down, nobody can access their Archive Mailbox as they normally would, so monitoring and maintenance is required (although perhaps at a lower degree if Archive mailboxes are deemed less important). Another downside could be when the internet connection fails. Users can access their on-premises mailbox but not their Online Archive Mailbox.

Depending were your company is based or what kind of industry your company is operating, it could very well be that certain privacy or security guidelines or even laws limit or prevent you from using this solution. Especially in Europe (semi) governments aren’t always allowed to store information off-premise or on servers that could potentially be outside the country (not even if it’s an fellow EU country). But even if you don’t have these legal prohibitions, there are still a lot of companies that don’t like to store their data (al be it older mails) off-premises with another company. Keep that in mind.

Benefits:

No local storage of archived data
Can be cheaper per GB than on-premises storage
No maintenance of archived data

Drawbacks:

Need for additional (Federation Services and DirSync) servers
Need for internet connection when access to Archive Mailbox is needed
Additional administrative effort on maintaining the Hybrid configurations
Additional fees per mailbox per month (however they are predictable)
Data is stored off premises which could have legal ramifications
The no control over your data could be a psychological barrier for some

Exchange Online Archive can be an easy solution depending on your situation, however most of the times legal and psychological barriers prevent you using this option.

This concludes part 2 of this series. The next and final part will discuss retention policies, mailbox quota’s and little bit about Outlook 2013.

Managing mailbox storage use in Exchange 2010, Part 1
Managing mailbox storage use in Exchange 2010, Part 3

The Windows 8 Mail app

dmstork — Tue, 27 Nov 2012 07:39:00 GMT

A few hours back the Microsoft Exchange team published a blog post on how to connect and support your Windows 8 Mail app with Exchange. It has a lot of good info on which Exchange ActiveSync (EAS) policy settings are supported and how the App reacts.

Most of those things I already discovered in earlier blog posts of mine, using the Windows 8 Consumer Preview. It seem as if there are no massive changes since then. But I did dig somewhat deeper into some specific features. So, check my two blog posts out as well:

Yes, there is ActiveSync in Windows 8!
More about Windows 8 CP and ActiveSync

Exchange SSL Offloading and the upcoming update blocking certificates with RSA key length less than 1024bit

dmstork — Wed, 13 Jun 2012 09:29:00 GMT

Microsoft announced yesterday new approach regarding the validation of certificates coming in august this year. Certificates with a key length less than 1024bit will be blocked:

Adding to our defense-in-depth measures, in August, we will release a change to how Windows manages certificates that have RSA keys of less than 1024 bits in length. Once this key length update is released, we will treat all of these certificates as invalid, even if they are currently valid and signed by a trusted certificate authority. We’re announcing this now to allow folks time to make needed adjustments. Further information on this change can be found on the PKI blog.

As 512 bit key length are not regarded as safe anymore quite some time now, this is a good thing. However, there are instances when this key length is not a major issue.

Consider the following scenario:
You have an Exchange 2010 organization with at least two Client Access servers and you use a Client Access Array (CAS Array). A Network Load Balancer (LB) is the endpoint for the CAS Array IP and has been configured with SSL Offloading. However, company policy dictates that (when possible) no unencrypted transmission of data occurs. As the internal network already has some security in place, this does not have to be high-grade security.
Thus, the admin chooses to use SSL from the LB to the Exchange Client Access Servers (Reverse SLL/SSL Bridging). To limit the load on the servers, she or he chooses a 512 bit key length for the certificate used between Exchange and the LB. This TechNet Wiki article by Henrik Walther describes these configurations.

If I understand the articles regarding the change on certificate validation correctly, Reverse SSL/SSL Bridging with a 512 bit key length certificate on the Client Access servers will not work anymore when this update is installed on these servers. I haven’t implemented these scenarios, but I know the 512 bit key length option is described either by Microsoft or LB vendors (can’t find them though…).

To be clear, this is only an issue when using 512 bit key length certificates! Solution would be to use at least 1024 bit key length certificates or discontinue the use of Reverse SLL before august. If someone know other options, let me know!

Update Rollup 3 for Exchange 2010 Service Pack 2

dmstork — Tue, 29 May 2012 20:12:00 GMT

Just today Microsoft released the third rollup for Exchange Server 2010 Service Pack 2. See the announcement here.

They specifically call out the following fixes.

KB2689810 Meeting Requests bodies get rendered in plain text in Outlook when created via Exchange Web Services.
KB2674445 Need the function to check ACL consistency during moving mailbox.
KB2700705 RpcClientAccess crashes with SocketException when UDP push notification is enabled.
KB2705425 Memory Leak in UMWorkerProcess.exe.
KB2698976 MRM Assistant doesnt process a mailbox with a contact created in other tenants.

I however noticed in this complete overview some other interesting fixes:

"There were no writeable domain controllers found in Active Directory site" error message when you run the ExBPA tool in an Exchange Server 2010 organization
Got enough calls from coworkers regarding this issue (not the first bug in ExBPA I might add)…
MRM retention policy in the Junk E-Mail folder does not work when you manually move email messages in an Exchange Server 2010 environment
Ah, didn’t notice this issue. But these kind of retention policies are something I would like to be standard in any Exchange 2010. Good to know that SP1RU3 is the update to have.
The E-mail Signature text box is not editable in Outlook Web App when you use Google Chrome in an Exchange Server 2010 environment
Although I use Chrome primarily for all my browsing and thus for OWA, I didn’t ran into this issue myself (possibly because this was already fixed earlier in Office365?). But because I find the multi-browser support in Exchange 2010 a very important feature, this fix could not go unmentioned.
You cannot move a mailbox in an Exchange Server 2010 environment that has a message size limit configured
Ahhh, this one make me and at least one big customer we have, very very happy. Consider the migration from GroupWise with no restrictions on message size (…) to Exchange. While you can (temporary during migration) set the message size very high, when you want to move the mailbox to another Exchange Database (quota, other RTO/RPO etc..) it would fail. Only option was to delete the message by admin (users couldn’t). This would hopefully resolve this!
You cannot move some users’ mailboxes from one Exchange Server 2010 mailbox database to another
Recently saw another (still unresolved) issue, in which we were unable to move mailboxes between databases on the same server. Although this case has some other error messages and possibly another root cause, this is something to keep in mind.
You cannot set the "Country/region" attribute of a user mailbox to "Curaçao," "Bonaire, Sint Eustatius and Saba," or "Sint Maarten (Dutch part)" by using the Exchange Management Console on an Exchange Server 2010 server
Residents of the Kingdom of the Netherlands will be pleased to see this fix

Yep, going to test this update in the lab ASAP

Managing mailbox storage use in Exchange 2010, Part 1

dmstork — Thu, 24 May 2012 14:33:00 GMT

It's something most organizations encounter at some point: A mail server with no more space left or user's can't get a higher quota due to limited storage resources. Even with a basic policy regarding mailbox quota's, running out of resources is still something that can happen if the server was not sized properly or upgraded to handle changed conditions (larger quota's, more mailboxes etc.).

Most straightforward would be upgrading the storage solution, but there are other options that could be a better fit for your organization. In this series of posts I will summarize the most common solutions I have encountered, implemented or even advised against.

PST

The Outlook Personal Folders file (or Personal Store with extension PST) are a very commonly used under these circumstances. Users often can make them without restrictions. An admin has to make effort to prohibit usage and there are also no extra licenses necessary, which means that there is no real incentive to restrict it at first. However, as time has probably taught most (Exchange) admins by now, there are a lot of reasons NOT to use PST files:

Only available via an Outlook client (and only one at a time), not via ActiveSync devices and/or Outlook Web App.
There is no oversight on storage usage, although when placed on an fileserver a quota could be implemented but:
Stored on a network share is not a supported situation by Microsoft (See KB297019; problems with shares and slower performance are important reasons)
Stored on local machines limits availability to exclusively that machine.
Backup could be problematic while in use and/or when on local machine (most synchronization tools ignore PST's, including Offline Folders).
Chance of theft (when on laptop) and corruption and thus loss of complete content of PST file.
There is no uniform search function, searching for mail has to be performed explicitly within PST.

Just don't use PSTs. In my experience a lot of Service desk time will be spent resolving some of the issues resulting from their use. It’s probably the IT department were the term ‘PST Hell’ was coined first.

You can use them for permanent export of mailboxes or as an migration intermediate. But not as a day-to-data mailbox extension. It is possible to restrict the use of PST's via registry settings or Group Policies.

On-premises Personal Archive

A new feature of Exchange 2010 is the Personal Archive function, not to be confused with Auto-archiving within Outlook. Basically, users get a second mailbox on Exchange with a separate quota. That Archive mailbox is available while connected to Exchange via Outlook (2007 & 2010) and Outlook Web App. It was actually devised as a possible solution to the aforementioned ‘PST hell’. More general info here.

Benefits are:

Look and feel of PST, so if PST were used users are used to it
Available via Outlook Web App.
Uniform search (one search query for main and archive mailbox).
Management of Archive mailboxes basically the same, so relatively low impact.
With Exchange 2010 Service Pack 1 Archive Mailbox can be placed in other database and thus other (cheaper) storage solution than main mailbox (i.e. storage tiering). This also make a different RTO/RPO possible (lower backup frequency, no redundancy via DAG etc. etc.)
Admins can control the retention and archiving of items via Retention Policies and give some control to users via Personal Tags.

But there are some drawbacks as well:

Two locations within Outlook (Web App) which contain mail instead of one central mailbox.
Although users can drag-drop items, automation policies are retention (time) based. User could still be confronted by his/her quota and will have to move items manually.
Only available when online (i.e. there is no caching in Outlook, this could also seen as a benefit BTW).
No compliancy enforcement, user are still able to delete/edit mail items.
No access via ActiveSync devices.
Optimal use only with Outlook 2010, Outlook 2007 has access with correct patches.
Office Professional Plus is needed.
Exchange Enterprise CAL needed per user with Archive Mailbox.

Only since Exchange 2010 Service Pack 1 the Archive Mailbox became IMHO a viable tool for Exchange storage management, due of the option of placing it in another database. It adds flexibility in a lot of scenarios. Possibly preventing the need for a storage upgrade, for instance when the Archive Mailboxes are moved to a Database not made redundant via DAG.

There are possible costs involved depending on you situation, you still need storage (but possible less) and Enterprise CALs (which could already be in possession). Each organization has to determine whether this method is one they would appreciate.

It's easy to implement, just click Enable Archive on the user object within the Exchange Management Console (EMC). Other management of those mailboxes is basically the same as normal mailboxes. The use of Retention Policies and Personal Tags is somewhat more complex however, but implementation other than the default policy settings is probably only a one time thing.

Concluding

We've discussed issues with storage use within Exchange and discussed the pro/cons of PST files and Online Archive. This concludes part 1 of this 3 part series of posts. The next post will discuss third party archiving solutions and Exchange Online Archiving.

Managing mailbox storage use in Exchange 2010, Part 2
Managing mailbox storage use in Exchange 2010, Part 3

Exchange 15 OWA Offline and Extensible?

dmstork — Fri, 20 Apr 2012 18:47:00 GMT

A few hours ago Mary-Jo Foley posted a blog in which she states (among other things not mentioned here) that the next version of Exchange (codename Exchange 15) could get an offline OWA. A requirement would be IE10.

Considering Windows 8 tablets, this could be quite the competitor for Microsoft's own ActiveSync (EAS, also incorporated in all versions of Windows 8). It would depend on the functionality while in offline mode; it’s only reasonable to assume functionality is limited when offline.

Offline OWA (OOWA? ) could be also interesting for those who don't want ActiveSync due to imposed (security) policies for instance. It will be interesting to see how this would impact Mobile Device Management in regards to BYOD, as SCCM 2012 and Windows Intune use ActiveSync for this purpose. I would expect a server side disable switch for this option in updated OWA Policies, but I suppose a remote wipe option would be harder to realize. But then again, the Windows 8 Mail app only removes relevant data and Windows does not revert to a factory state. The same strategy could be used here and should probably be sufficient.

In my opinion that wasn't actually the most interesting of her post, it mentioned the possibility of OWA Extensibility. Customization of OWA was pretty much limited to editing themes and adding functionality like Microsoft Lync integration. If this rumor is true, that could be quite exciting depending on the scope of possibilities and to what extent it will be supported by Microsoft. Perhaps part of your business application inline in OWA? Where would the limits be? Will this this also be possible with Offline OWA?

But remember, this is not confirmed by Microsoft. But my mind was already exploring the opportunities and caveats of these (hypothetical) features and I just had to share them. Finally some good rumors regarding Exchange 15!

Exchange 2010 calendar publishing URLs are not updated after migrating to Office 365

dmstork — Thu, 15 Mar 2012 13:36:04 GMT

With Exchange 2010 Service Pack 1 it became possible to share your calendar with anyone outside of you organization, depending on the Sharing Policy implemented by your Exchange Administrator. Users can then share their calendar via an obfuscated or an relatively public URL without the need for authentication (and SSL for that matter). For more information on how to prepare your environment if you want to enable it, see this blog post.

However, if an user has this enabled on an On-Premises Exchange environment and is then migrated to Office 365 the URL pointing to the published calendar is not updated and will probably not work.

I migrated my personal on-premises Exchange account to an Office 365 P1 subscription, after that the URL did not work anymore. This was logical as the original URL did not point to a published Exchange server from Office 365 (which uses *.outlook.com, at least for P1 plans).

Disabling (Stop Publishing) and (re)enabling calendar sharing by the user generated a correct URL and calendar sharing worked perfectly fine after that.

More about Windows 8 CP and ActiveSync

dmstork — Fri, 02 Mar 2012 15:36:04 GMT

Since yesterday’s blog post “Yes, there is ActiveSync in Windows 8!”, I have fiddled some more with the Windows 8 Mail app.

So, which other ActiveSync settings do work within Windows 8? There are quite a few, and some aren’t supported by all devices. So, which are important and could I use as a baseline? Well, Microsoft already made a baseline:

Exchange ActiveSync Logo Program

The Exchange ActiveSync Logo program was created to easily identify devices which had a certain minimum ActiveSync capabilities. I have checked to see whether these options are available in the Windows 8 Mail app:

Direct Push email, contacts & calendar – Yes
Accept, Decline & Tentatively Accept meetings – No (not within Mail or Calendar App)
Rich formatted email (HTML) – Yes
Reply/Forward state on email – Partial. Not from Mail app to Exchange, other way yes
GAL Lookup – No (in both Mail and People app)
Autodiscover – Yes
ABQ strings (device type and model) provided – Yes & Yes*
Remote Wipe – Well, not whole device. No?
Password Required – Yes
Minimum Password Length – Unknown
Timeout without User Input – Yes
Number of Failed Attempts – Yes

* Device Family is “WindowsMail” and Model has two entries: “Windows PC” and “WindowsMail”.

So, no Logo then…

ActiveSync password settings

The ActiveSync password settings are a bit funny though, as I log into Windows 8 with my Live account. That account has it’s own password rules. This will also be the case with domain joined computers. Furthermore, I’m guessing that the local computer security settings also provide a baseline rule.

I did notice that Windows 8 locked itself sooner due to the 1 minute time-out setting in the ActiveSync policy. Which makes this the first indication that some ActiveSync settings do affect the OS directly.

The maximum number of failed attempts was also a affected by ActiveSync, normally you get a warning after about 5/6 wrong entries. With a Failed Attempts setting of 4 (the minimum) you get the same warning:

So no wipe, just a reboot. I’ve checked and all data and settings where still present. If you check the options in the Exchange Control panel, it mentions wipe:

Concluding this part: After setting only the four settings mentioned in the logo program Exchange regards the policy as fully applied:

How about some other features?

I’ve made some changes in my default Exchange ActiveSync Policy in order to further test the ActiveSync implementation not part of the Logo program. I choose some that were easy to check on my virtual Windows 8 device:

Limit email size to (KB): 10 (was unlimited)
Allow attachments to be downloaded to device: Unchecked (was Checked)
Allow camera: Unchecked (was Checked)

Limit email size

I could read mails larger than 10KB in the Mail app and on my iPad, but not on Windows Phone 7.5

Allow attachments

Can’t save (right click on icon) it anymore and can’t downloaded it. Same behavior as most ActiveSync devices.

Allow camera

My virtual Windows 8 CP didn’t have a camera, so this is a bit speculating. But if you check the permissions within the app (Charm bar>Permissions), you can set the camera permission manually. The Webcam and Microphone permission is disabled at default. After enabling it and changing the EAS policy, the option was still enabled.

It is not a 100% check, but interesting enough… The Camera app was also still present. Surprising enough it also still works within Windows Phone 7.

Within iOS (my iPad 2) all camera related apps disappear. It would be interesting to see this (and other) function work, especially on Windows 8 slates/tablets.

And on Exchange

Let’s see on the Exchange end how the new EAS policy is applied.

Ha, it’s partially applied! This is probably the Camera setting and it’s positive that this is visible in feedback.

Conclusion

So, ActiveSync in Windows 8? Well, not exactly.

As stated, it does not deliver all the features as required by the Exchange ActiveSync Logo Program (EALP). If this doesn’t change, this would mean no Windows 8 device would receive the ActiveSync logo.

Furthermore, the functionality is apparently (mostly) confined to the Mail app within Windows 8. The most important proof of this is the remote wipe option, which only wipes the synced information and not the whole device.

The above observation is an important distinction as ActiveSync policies are mostly only valid within the App and not the OS. Aside from the partial Remote Wipe, this could have some impact on Mobile Device Management for Windows 8 devices, especially Windows on ARM (WOA).

As we are told that WOA would have almost no differences regarding the x86 versions, this would mean that ActiveSync functionality would also be an App and not OS functionality. We can somewhat expect that WOA devices will not be EALP compliant as the iPad is.

This is another indication on how Microsoft regards WOA; a consumer device as ActiveSync policies are more Enterprise features. It is however still possible that functionality will change in the coming months. I personally would hope so, as I regard ActiveSync as a sort of light mobile device management tool.

If an organization will not have WOA devices, there are ActiveSync Device Security settings that do have an impact on Windows 8 (x86 based) computers. Which setting will win? ActiveSync polices? Active Directory Polices? Or the most constricting one? This will undoubted lead to interesting discussions between users, those responsible for Exchange ActiveSync policies and those for Active Directory Group Policies…

Granted, most organizations probably also have Outlook (2010 with the option of multiple accounts) and thus no need for the Windows 8 Mail app. But still, I already think it a best practice to at least consider blocking out the Mail app within AD environments…