Category: Exchange Server

• Windows Server 2012 R2 Support
• S/MIME support for OWA
• Edge Transport Server Role
• Various Fixes and Improvements

Implementing digital signatures in Exchange/Outlook environment is not a very complex. However, it requires that you understand how this technology work, and also must have some infrastructure background implemented.
Digital signatures actually protect the content integrity. They don’t provide any protection in a meaning that content of the message can’t be intercepted and read by someone else. However, if the content is altered during transport, digital signature will alert you on this.

When an author digitally signs a document or a message, the operating system on his machine creates a message digest which ranges from between a 128-bit and to a 256-bit number. It is generated by running the entire message through a hash algorithm. This number then is then encrypted by using the author’s private key, and then it is added to the end of the document or message.

When the document or message reaches the recipient, it will go through same hash algorithm as when it was digitally signed. Also, the recipient uses the author’s public key to decrypt the digest that is added to the message. After it is decrypted, it is compared to the digest that the recipient has generated. If they are the same, the document or the message was not altered during transport. Also, if the recipient is able to decrypt the digest by using the author’s public key, this means that the digest was encrypted by using author’s private key, and that confirms the author’s identity. At the end, the recipient also verifies the certificate that was used to prove author’s identity. During this check, the validity period, CRL, subject name, and certificate chain trust also are verified. Make sure that certificates that you use for digital signatures have valid CDP and AIA locations defined.

To implement digital signatures in internal communications, you just need to issue certificates based on the User template. This certificate template is present by default on each Windows Server CA. Of course, you can also use a custom template for this, or you can use smart card certificates for digital signature. This is actually pretty common if smart card infrastructure is deployed. You must issue certificates to all users that who use digital signatures, as authors (don’t need to have one just to read digitally signed message). You can issue the certificate without any user intervention if you use autoenrollment. Also, users must use an application that supports content signing. The digital signatures are ready to be used after the certificate is issued and configured in the application. Certificate for digital signature will be mostly automatically configured in Outlook, so the end user will not need to perform any configuration. If you want to use digital signature in OWA, you will need to install latest S/MIME controls. For mobile platforms and digital signatures, things are not so simple. At the moment, most mobile platforms do not support functionality of digital signature in an email (although ActiveSync does support it on protocol level).

However, if you want to send digitally signed content outside of your organization, you can experience CA trust issues. In this scenario, a recipient is not in the same domain as the author, so it does not trust a the CA that issued a the certificate for the digital signature. Although this kind of digital signature will still be valid from the aspect of content protection perspective, an application being used will probably generate a warning on the recipient side.

If you have a need to send digitally signed content to recipients outside of your organization, I recommended that you buy certificates from a public, globally trusted, CA.

For all of who wait for a first SP before you deploy new version of Exchange Server, think again. While Microsoft will still ship Service Packs for Exchange, they also decided to go with more frequent updates, released quarterly, in order to fix most significant bugs, but also to provide new functionalities.

Yesterday, Cumulative Update 2 for Exchange Server 2013 was released, and besides fixing some known (and unknown) bugs, it provides pretty much of new and enhanced functionalities. In these areas, Microsoft has provided new or improved functionalities:

CU2 can be downloaded here: Exchange Server 2013 CU2. As before, this is full install, rather then just an incremental upgrade, but you can use it for both purposes – green field installation or upgrade of existing Exchange 2013. Microsoft still didn’t publish release notes for CU2, but pretty good overview of what’s new can be found here.

Ever since Exchange Server 2013 was released some users are experiencing pretty annoying mail flow issue, mostly manifested like messages stuck in Outbox or Drafts folder in Outlook or Outlook Web App.

While this issue is still not officially confirmed by Microsoft, there are, however, several solutions that can resolve it. In this post, I will present solutions known so far to resolve this. Before you start, make sure that you have latest CU installed on your Exchange Server 2013.

First, you should check if mail flow issue is maybe caused by performance issue on Exchange server. Sometime, if the Exchange server is low on system resources, it will stop some services. If you have performance issue with your Exchange, you will definitely have it recorded in Event Viewer, so make sure that you check that first.

If you are fine with available resources and performance, but still experiencing mail flow issue, try to manually restart Exchange transport services. If you are running both CAS and MBX roles on the same machine, you have to restart these three services : Microsoft Exchange Frontend Transport, Microsoft Exchange Transport Delivery and Microsoft Exchange Transport Submission. This usually helps if you experience mail flow issue after your restart your Exchange server.

DNS configuration on the Exchange Server is also pretty usual cause for mail flow issue. To make sure that you have proper DNS configuration, open Exchange Admin center, navigate to servers, and then select your Exchange server(s) and click Edit on toolbar. Now, navigate to DNS lookups, select your network adapter and manually enter the DNS server that your Exchange server should use for internal and external lookups. Most likely, it will be your local DNS.

If this doesn’t help, you can also try to prevent your Exchange transport from using DNS IPv6. However, for this, you should edit Exchange transport config files. Navigate to your Exchange installation folder, open BIN directory and find following files:

· Edgetransport.exe.config

· Msexchagnesubmission.exe.config

· MSExchangedelivery.exe.config

To each of these files, you should add following line:

<add key= "DnsIpv6Enabled"  value = "false” />

Be aware, however, that EdgeTransport.exe.config  file already has the entry but it is sent to true, so you should just change it to false.

After you do this, it is recommended to restart transport services, or the whole Exchange server.

If you have your own solution for mail flow issue, not listed here, post a comment.

After you enabled Mailbox Replication Proxy service on the source Exchange Server, it is a good idea to test its functionality. You can easily do it by executing Test-MRSHealth cmdlet. Make sure that you have value True in each Passed row, for each test, and you’re good to go.

Before actually moving a mailbox, you should prepare it for moving. Actually, you have to migrate a user object first and prepare mailbox move request. Luckily, Microsoft has provided a script for this. Steps for preparing an object move are as follows:

1.       Open Exchange Management Shell on the destination CAS server and change the path to “C:\Program Files\Microsoft\Exchange Server\v15\scripts”

2.       Type, $Local = Get-Credential and press Enter. When prompted, provide admin credentials for new (destination) organization. That is the org to which you move the mailbox.

3.       Type $Remote= Get-Credential and provide credentials for source organization. By executing these steps we are actually storing credentials for administrators in both organizations. These credentials are used by the script in the next step.

4.      Type:

.\Prepare-MoveRequest.Ps1 -Identity “User UPN” -RemoteForestDomainController FQDN_OF_SourceDC -RemoteForestCredential $Remote -LocalForestDomainController FQDN_OF_LocalDC -LocalForestCredential $Local -TargetMailUserOU "OU=OUNAme,dc=domain,dc=extension"  – you should fill italic text with your own values
(example : .\Prepare-MoveRequest.Ps1 -Identity Damir@dizdarevic.ba -RemoteForestDomainController dc-srv-01.dizdarevic.ba -RemoteForestCredential $Remote -LocalForestDomainController dc-srv-01.dizdarevic.local -LocalForestCredential $Local -TargetMailUserOU "OU=IT,dc=dizdarevic,dc=local" )

5.       After you execute this PS script you should get the reply : 1 mailbox(es) ready to move

Now, if you open Active Directory Users&Computers in destination domain, you should find user object created (and disabled, since we didn’t move password). If the object is there, we are ready to move the mailbox. We will do it in Exchange Admin Center in Exchange Server 2013.

So, open EAC and perform following:

Click recipients and then click the migration tab. Click New and choose Move to this forest option. In a wizard, click Add and select the user that you just moved. Actually, here you will see only users that are moved using procedure described earlier. Enter credentials for remote/source forest and confirm the name of migration endpoint – that is FQDN of the server where you enabled MRS Proxy service. After that choose the destination database for the mailbox and confirm the admin credentials. Start the migration batch. After that wait for a few minutes until status of user object becomes Synced. Then click Complete this migration batch and wait until the status of the object becomes Completed. And, you’re done!

After mailbox is migrated, all you have to do is to set the password on the moved user account and to enable that account. After that, user can login in the new forest, and will have its mailbox content moved.

So, as you can see, the process is not simple, but it can be done if you carefully follow the steps I provided. If you have troubles, let me know – maybe I can help.

Moving mailboxes between different Exchange organizations (which means different AD forests) is not something that is easy thing to do. Luckily, it’s not something you do every day, but when you need it, it’s better to have procedure ready and tested. While authoring 20342 MOC course (Exchange 2013 Advanced Solution) I was making a lab for moving Exchange mailboxes between different Exchange organizations, and I must admit that I spent quite amount of time to make it work. That’s why I decided to pull some important parts and make them available to all my readers.

First, why would you want to do this? As I said, occasions for this procedure are not often, but sometimes you just have to do this. For example, if you merge two organizations or if you want to have a fresh start with new AD DS and new Exchange, while all your resources are still in old AD DS. Whichever reason you have, you’ll have the same starting point which is – accounts and mailboxes in one organization (Let’s call it OrgA) and (fresh) AD DS and Exchange in another organization (Let’s call it OrgB). When saying organization, I mean Exchange organization, not necessarily another company (but mandatory another AD DS forest). Let’s presume that OrgA has Exchange Server 2010 deployed, while OrgB has Exchange Server 2013, and we want to move mailboxes from OrgA to OrgB.

Since Exchange Server is very deeply integrated with AD DS, you can’t just move mailboxes – it’s a bit more than that. You also have to move user objects. This can be done in several ways. Easiest thing to do is to use ADMT (Active Directory Migration Tool) which can greatly help in moving AD accounts from one domain to another, together with all attributes, as well as with password sync. You can also use ForeFront Identity Manager for this purpose, although it might be a bit complicated to deploy FIM just to do this, but if you have it in place, you can use it to provision user account objects in another domain. ADMT is definitely best choice, however, at this time, we still don’t have ADMT that can move user objects from Windows Server 2008 domain to Windows Server 2012 domain.

Luckily, there is a script in Exchange Server 2013, which can great help in doing this. The script prepares the AD DS target object and synchronizes the required attributes for cross-forest moves to work. The script creates the mail enabled user account in the target forest if necessary, or it synchronizes an existing user when possible. This script is called Prepare-MoveRequest.ps1, and it is in the Program Files\Microsoft\Exchange Server\V15\Scripts folder. This script is fairly simple to use, but be aware that this script does not move passwords, so user account that you move will be disabled (and without password) when you move it to OrgB. If you can live with this, you’ll be fine. Otherwise, you will have to use ADMT to move user objects, but then you should be aware that this script in Exchange Server 2010 is not fully compatible with user objects moved with ADMT, at least with current version of ADMT. This is because ADMT does not migrate Exchange attributes on user object, which can cause account in destination domain to look like a legacy Exchange account. The Prepare-MoveRequest script in Exchange Server 2013 supports a new parameter, OverwriteLocalObject, for user objects created by ADMT. The script copies the mandatory Exchange Server attributes from the source forest user to the target user.

Ok, let’s now see how to do this. First, you have to do some preparations in OrgA in OrgB. In a nutshell, you have to do following:

· Make sure that connection between OrgA and OrgB is reliable. Also, make sure that name resolution between domains in OrgA and OrgB is working

· Establish forest trust between OrgA and OrgB. While this is not mandatory, it will definitely make your life easier during this procedure. You can remove the trust later.

· Deploy mutually trusted certificates on Exchange server in both organizations. You can achieve this in various ways, I will not elaborate on this – just make sure that each Exchange trusts certificate on another one

After you did all these preparation steps, you should make sure that Mailbox Replication Proxy (MRSProxy) service on the Client Access server in the source Exchange Server organization is running. By default, this service is disabled, and you’ll probably have to make it start. Easiest way to do this is to execute following in EMS:

Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSProxyEnabled $true

Before executing this command it is wise to check identity of your Web services virtual directory. Default value is like in command I just wrote, but it can be different. So, run Get-WebServicesVirtualDirectory | FL and check for the identity attribute.

With Set-WebServicesVirtualDirectory cmdlet you can also use MaxMRSConnections parameter. The value of this parameter establishes how many mailbox moves you can do simultaneously. The default value is 100. You should reduce this number if the mailbox move is going across a slow link. If you have reliable and fast connection, you can forget about this. But, if you change the value, you should restart Mailbox Replication Service for the change to take effect.

Before you proceed, there is one thing that you should check to spare some headaches later. When you enable the Mailbox Replication Proxy service on the source Client Access servers, the mailbox move endpoint becomes MrsProxy.svc. In some cases, the IIS configuration is missing the svc-Integrated handler mapping, which results in an error, such as “(405) method not allowed,” when you start moving mailboxes, and that’s not something you want to see. To make sure that this will work, open command line at this path: C:\Windows\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\ , and then execute the following command: ServiceModelReg.exe –r. This command reinstalls the handler mappings in IIS. To check for existing handler mappings in IIS, start the IIS console and then, in the center pane, double-click Handler Mappings, while the virtual directory or website is selected. Just make sure that you see *.svc there.

Now that we have things prepared, we will start moving some mailboxes in next part of this article. Stay there.

Microsoft has released an update for PST import tool which now can work with both Exchange 2013 and Exchange Online. Can be very useful if you want to migrate mail content from user’s machines to their mailboxes.

Download here : http://www.microsoft.com/en-us/download/details.aspx?id=36789

A need to protect SMTP traffic is not uncommon. In general, you can’t always protect it. Inside your organization, it’s pretty easy – you can easily implement digital signatures or encryption for emails, but if you want to go outside, things are becoming more complicated. You can still use digital signing (S/MIME) on emails, but if your certificate is issued by your internal PKI, it probably won’t be trusted on recipient side. That will not prevent functionality of digital signature, but will affect trust.

If you want to send encrypted emails outside your organization, things are even more complicated. If you want to use just built-in Outlook features for message encryption, you will need to have public key of any recipient that you want to send encrypted message to. Inside your organization, this is not an issue as you can publish certificates in AD DS. However, outside, on the Internet this is not an easy job. Sure, there are some third party tools for this, but let’s see what we can do without them.

Domain Security is a feature of Exchange Server (both 2010 and 2013) that can secure SMTP traffic between two Exchange organizations. It is implemented on server level, and it works without configuring any options on user (sender or recipient) side. Domain Security uses mutual TLS authentication to provide session-based authentication and encryption. Mutual TLS authentication is different from TLS as it’s usually implemented. Usually, when you implement TLS, client will verify the server certificate, and authenticate the server, before establishing a connection.

With mutual TLS authentication, each server verifies the connection with the other server by validating a certificate that’s provided by that other server, so clients are not included at all. We establish secure SMTP channel between two Exchange Servers, usually over the Internet.
Clients, Outlook and Outlook Web App, will be aware that Domain Security is established. Green icon with check mark will be shown on each messages exchanged between servers on which Domain Security is implemented.

As you can see, Domain Security can be applied between two (or more) known Exchange organizations. Still, it can’t protect whole SMTP traffic that comes and goes from your Exchange organization, but it can efficiently protect SMTP traffic between partner organizations.

Let’s see how to configure it. I’ll show the procedure for Exchange Server 2013, but most of it can be applied to Exchange Server 2010 also. Let’s assume that we want to establish Domain Security between two Exchange organizations named adatum.com and treyresearch.net (Yes, I’m using domain names from Microsoft Learning courses, but since I write these courses, I just get used to that )

1. Establish certificate trust between organizations

As said before, Domain Security relies on certificates. Because of this, you should first establish certificate trust between two organizations where you want to implement Domain Security. You can do it on several ways. If both organizations are using publicly trusted certificate on Exchange servers, you are good to go. If that’s not the case you will have to cross-import Root CA certificates on both sides. Alternatively, you can also issue certificates for SMTP for both Exchange organization from a single trusted RootCA. Anyway, the point is that each Exchange server must trust the certificate installed (and assigned to SMTP service) on another Exchange server. Achieve this in any way you like. Besides establishing trust, make sure that certificate common name is same as the name that Exchange server provides in HELO/EHLO conversation.

However, it’s important to notice one thing here. In Exchange Server 2010, you would be doing this on Edge Transport server or if you didn’t deploy one, on Hub Transport server. Since these two roles are no more in Exchange 2013, these certificates should be installed on CAS servers which, in Exchange Server 2013, host FrontEnd Transport Service. Also, it is important that certificate you want to use for Domain Security is assigned to SMTP (it can be assigned to other services as well)

2. Configure Domain Security

As both sides/companies will be sending and receiving emails, following procedure should be done on both sides, but domain names should be used vice-versa.

First, open Exchange Management Shell and execute this cmdlet :

Get-TransportConfig | FL

You will get whole list of transport settings but we want two of them : TLSReceiveDomainSecureList and TLSSendDomainSecureList. If you were not configuring Domain Security so far, you will have these two values empty. To use Domain Security we must populate these parameters with appropriate values.
TLSReceiveDomainSecureList – specifies the domains from which you want to receive domain secured email by using mutual Transport Layer Security (TLS) authentication
TLSSendDomainSecureList – specifies the domains from which you want to send domain secured email by using mutual TLS authentication

If we are on adatum.com side, we will execute following:

Set-TransportConfig -TLSSendDomainSecureList adatum.com and
Set-TransportConfig –TLSReceiveDomainSecureList treyresereach.net

After this, when you run the Get cmdlet again you should have these values:

Logically, on treyresearch side we will issue same commands but domains will be inverted. If you have more than one company with requirement for Domain Security, you can provide their domain names too. This cmdlet accepts multivalued parameters.

3. Configure connectors

Now, we will create dedicated connectors for Domain Security. Let’s first create the send connector. You can use Exchange Admin center for this. Navigate to mail flow, click Send connectors and add new one. In a wizard, type the name of the connector and select Partner type. Don’t use the smart host, but leave MX record as a method to send mail. For connector address space, type the domain name from other Exchange organization. If you are on Adatum.com side, you will type treyresearch.net. On the source server page of wizard, select Mailbox server that you want to use as a source. It doesn’t matter which one you will choose since we will configure connector to proxy through CAS. When you create the connector, double click it and then enable options “Proxy through client access server”. You can also configure maximum message size for this connector if you want, and enable protocol logging.

Now back to Exchange Management Shell,and execute :

Get-SendConnector –identity ConnectorName | FL

Look for the value of parameter DomainSecureEnabled. It should be True. If it’s not you can easily set it with Set-SendConnector –identity ConnectorName –DomainSecureEnabled:$true

Let’s now configure Receive connector. Back to EAC, click mail flow and then click receive connectors. In Select server drop-down list choose your Client Access server.

Select Partner for connector type, configure receiving IP address if you want (or just leave all available) but on remote network settings page, you should configure only the IP address assigned to another organization Exchange server. This should be (public) IP from which partner’s Exchange server sends email. After you create the connector double click it, and click on security tab. Make sure that authentication options are set like on following screenshot.

4. Test the Domain Security

Easiest way to test this is to just send email from one organization to another from Outlook. If you get the message with green check mark, you are all set. If not, then you’ll need some troubleshooting. You can enable protocol logging by executing :

Set-ReceiveConnector Internet -ProtocolLoggingLevel Verbose, and

Set-SendConnector Internet -ProtocolLoggingLevel Verbose

to verify TLS channel. If message doesn’t arrive to recipient but doesn’t come back as NDR, you should check queue.

Or you can just wait for my next blog post, where I will discuss some troubleshooting .

Few days ago I tried to import my personal certificate (by Verisign) to Windows Phone 8 device. I exported it as .pfx, sent to my self in a email and then opened it on device. It worked. Sort of. I mean, WP did import the certificate but didn’t provide any clue what I can do with it. I tried to find option to digitally sign or encrypt email, but with no luck. Next thing that came up on my mind was certificate based authentication to Exchange Server. Then I’ve found this article. It seems like WP8 now fully supports certificate based authentication against Exchange Client Access Server. However, my personal certificate issued by Verisign, will not be of any use here as it is not issued by my internal PKI. Will have to get new one and put it on device, and then I will try this.

This seems to be very useful option for authentication to CAS. I think that besides WP8, Android and iOS also support cert based authentication. I will try all three platforms and will post results here. And, it will be nice if WP8 has some certificate management implemented – now when you import the certificate, it’s like in a black hole, no way you can find or manage it (or I didn’t find a way to do it).