Exchange 2013 Wildcard There is a problem with the proxy server’s security certificate

Exchange 2013 Wildcard there is a problem with the proxy server’s security certificate

I have recently come across a problem that only seems to affect Outlook 2010 or Outlook 2007 when connecting to Exchange 2013 with a wildcard certificate. This was also an issue in Exchange 2007 and 2010 but was often less obvious as Outlook Anywhere didn’t tend to be as heavily used. This does’t seem to affect all Outlook clients and is possibly related to the patch level of Office so do first check that your Office installation is patched up to the supported version or higher.

So the symptoms are this, when you setup a mail profile and autodiscover runs it finds the server and username with no issue but then displays the following error:

There is a problem with the proxy server’s security certificate. The name on the security certificate is invalid or does not match the name of the target site

Outlook is unable to connect to the proxy server. (Error Code 0)

This is usually accompanied by a login prompt that never accepts your credentials and you get stuck in a credentials prompt loop.

Exchange 2013 Wildcard There is a problem with the proxy server's security certificate

There is a problem with the proxy server’s security certificate. The name on the security certificate is invalid or does not match the name of the target site Outlook is unable to connect to the proxy server. (Error Code 0)

This error is caused by the CertPrincipalName value being returned as the external URL of Outlook Anywhere e.g The name the certificate was issued to is actually * so Outlook is seeing this as a mismatch. You can manually correct the entry under the Connection tab and Exchange Proxy Settings but you will find that autodiscover will just change it back and next time you open Outlook the login prompt will be back.

The root cause of this is that Autodiscover gets the Outlook Anywhere settings from the Outlook Provider configuration, by default the CertPrincipalName is null so autodiscover uses the external URL of Outlook Anywhere, which is normally correct, except in the case of a wildcard certificate. To address this issue you will need to run the following in Exchange Management Shell:

Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*


Set-OutlookProvider -Identity EXCH -CertPrincipalName msstd:*

You will need to wait a while for this to update or you can restart the world wide web service.

Note that the EXCH provider is new, in past version of Exchange changing the EXPR provider would have resolved the issue on its own.

Next time you try to configure the Outlook profile you should find autodiscover completes error free and the principal name under Exchange Proxy Setting will the desired wildcard entry.

I have another post on Exchange 2013 Outlook Anywhere issues that present similar symptoms so if this wasn’t your issue head over here and check out a bunch of other potential Outlook Anywhere hurdles.

Thanks for reading and hope this helps some people out.

Scripting Exchange 2013 Installation and Configuration

Scripting Exchange 2013 Installation and Configuration

Scripting Exchange 2013 Installation and Configuration lets you deploy Exchange 2013 quickly and with minimal interaction. The result is an Exchange 2013 server with a basic configuration able to send and receive emails.


The benefit of scripting the installation and basic configuration of Exchange 2013 is that it is quick and you don’t have to hang around watching it. Another major advantage is that using a well tested script will result in your Exchange 2013 deployments being very consistent and predictable.

In most environments you will want to carry out additional configurations such as install an SSL certificate, creating additional receive connectors and additional databases etc.

The Install-Exchange2013.ps1 script can be found here:

Make sure you read the authors blog post to understand the different parameters and various ways you can use this script.

The other scripts can be found here:

The InstallExch.ps1 script is not really necessary you can just run the Install-Exchange2013.ps1 script directly, I create these for different scenarios so I don’t have to remember exactly which switches I used and type it all out each time. I use read-host so I can just run the script and answer the questions.

Use this script to quickly configure your Exchange 2013 virtual directories with minimum fuss. This has been changed from the one in the video, it now has a separate parameter for Autodiscover URL. Again I use read-host a lot as I prefer to just execute a script and answer some simple questions.

This simple script firstly checks if any send connectors already exists, if they do then it adds your server to them as a source transport server. If no send connectors exist it creates a default one for you. There is a parameter for smart host and if you leave it blank it will use MX records to deliver mail.

Make sure you understand what these scripts do and test them out in labs before you start using them in live environments, although running these scripts will deploy Exchange 2013 with basic functionality there are lots of scenarios where you would configure Exchange differently. These scripts will need modifying to suit different configurations and maybe even leaving one or two out and carrying out configurations manually will be needed. You need to understand Exchange 2013 when using these scripts, they are not intended to let you get away with deploying Exchange without some knowledge and experience. What they are intended to do is help you speed up your deployments and give you some ideas on how you can script some other common configurations.

Thanks for watching and reading.

Exchange 2013 Create CSV for Migration Batch

Exchange 2013 Create CSV for Migration Batch

Exchange 2013 Exchange Admin Center offers the ability to create migration batches from a CSV file.

This is a pretty handy feature if you want to speed up migrating users to your new Exchange 2013 deployment or even just need to move users from one database to another. For the CSV to work it simply needs one column headed “emailaddress”, which is great but also not so great seeing as the Get-Mailbox Exchange Management Shell cmdlet returns a heading of “PrimarySMTPAddress”. This minor irritation is no big deal, we can just re-label the column as part of the script.

So here is an example of a script that I use frequently when doing Exchange 2010 to Exchange 2013 migrations:

$OU = read-host "Which OU?"
$filepath = read-host "Filepath for CSV?"
get-mailbox -OrganizationalUnit $OU | select-object @{Expression={$_.primarysmtpaddress};Label="emailaddress"} | export-csv $filepath\"OU"$OU"batch.csv" -NoTypeInformation

This script lets me create mailbox move requests for users in a certain OU. It first of all asks you a couple of questions, just tell it which OU followed by the folder path where you want the CSV to end up. Please note though if you have multiple OU’s with the same name you will need to enter the full DN instead.

Once the script has run you can go to Exchange Admin Center and start a new local move request and then select “specify the users with a CSV file” and choose your CSV. Complete the wizard and you will see all users from your chosen OU queued up to move database.



Of course this script can easily be modified to get mailboxes from variables other than OU, security group for example is another option I frequently use. Another option is to get all users from one database and migrate them to another. You can also take this a step further and dispense with the GUI all together and just pipe in your output straight to the New-MigrationBatch cmdlet. Here is an example of the New-MigrationBatch cmdlet:

New-MigrationBatch –Name <name> –CSVData ([System.IO.File]::ReadAllBytes(“<full path to file>”)) –Local –TargetDatabase <dbname>

This on it’s own won’t kick off the migration batch, you will also need to execute this command:

Get-Migrationbatch | Start-MigrationBatch

We can combine these commands together into a single script or we can execute them separately. Every environment is different, for some migrating by OU won’t be appropriate so have a play around and see what works in your environment.

As always I hope this has been helpful to somebody. Thanks for reading.

Exchange 2013 Migration Outlook Anywhere Proxy Issues

Exchange 2013 Migration Outlook Anywhere Proxy Issues

One of the common problems I have come across when helping clients to migrate from Exchange 2007/2010 to Exchange 2013 is that while in Exchange 2013 coexistence RPC proxy doesn’t work. Sometimes these problems aren’t immediately apparent, some of the symptoms don’t become apparent until you migrate a mailbox back to your legacy Exchange 2007 or Exchange 2010 server. Problems may manifest as Outlook repeatedly prompting for credentials, users unable to access mailboxes, connectivity issues when accessing legacy public folders or users unable to access shared mailboxes and calendars. 

With Exchange 2007 and Exchange 2010 Outlook clients connect via MAPI by default. With Exchange 2013 Outlook clients can only connect via RPC over HTTPS or Outlook Anywhere. When in Exchange 2013 coexistence connectivity to mailboxes on Exchange 2007 or Exchange 2010 servers is proxied via the Exchange 2013 server. In order for the HTTPS proxy to work successfully the authentication settings on both Exchange 2013 and the legacy Exchange 2010 or 2007 server must be identical.

So first things first we must check how both Exchange 2013 and Exchange 2007/2010 servers have Outlook Anywhere configured. To do that login to an Exchange 2013 server and execute the following command in Exchange Management Shell:

Get-OutlookAnywhere | fl servername,externalclientauthenticationmethod,internalclientauthenticationmethod,iisauthenticationmethods

This should output something that looks a bit like this:


So in this case the settings are identical, if your output looks like this then great things should be working (read on though if they aren’t as there is one more thing to check). However, if the settings differ from server to server in any way you need to take corrective action. You can go for different authentication methods but they must match on both servers. In my experience though these settings work best i.e. NTLM on both internal and external and for IIS. Other authentication methods such as basic can lead to a few bugs while in co-existence so unless you have a specific reason to configure this differently then I would advise that NTLM is the best choice for a trouble free coexistence.

To set Outlook Anywhere to the same on all servers you can execute the following Exchange Management Shell command:

Get-OutlookAnywhere | Set-OutlookAnywhere -ExternalClientAuthenticationMethod NTLM -InternalClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM

Or you can set a server individually like this:

Set-OutlookAnywhere -Identity "EXCH1\rpc (Default Web Site)" -ExternalClientAuthenticationMethod NTLM -InternalClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM

At this point things should be working properly, however I have seen on a couple of occasions one more area that can cause some trouble. In IIS sometimes the Windows Authentication (NTLM) provider order can be mismatched between servers. To correct the provider order open Internet Information Services (IIS) Manager and click on the Rpc virtual directory. Next open authentication and you should see Windows Authentication is enabled. Click on Windows Authentication and then click on Providers… In the resulting window you can re-order the providers, you need to ensure the order is the same on all Client Access Servers.


Lastly whenever you make changes to the virtual directories you will need to perform an iisreset /noforce on each server to effect the changes immediately.

I find that misconfiguration of Outlook Anywhere accounts for most of the issue I see during Exchange 2013 coexistence so hopefully this helps some people out with their Exchange 2013 migrations.

**UPDATE** I recently came across another Outlook Anywhere / Autodiscover issue which could present with some similar symptoms. If the solutions above didn’t resolve for you and you are using a wildcard certificate then take a look at this.

Office 365 useful deployment information

Office 365 useful deployment information

I attended an Office 365 deployment fast track training session at Microsoft this week and came back with some interesting information (or it was to me but you guys might already know all this stuff). There seem to be some misconceptions in particular surrounding ADFS and whether it is a requirement for Hybrid deployments.

1.       You don’t need ADFS to do Hybrid. In respect of hybrid, ADFS gives you nothing except that authentication requests are sent back to on premises ADFS instead of dealt with by Azure. ADFS is only really needed for massive deployments (50k+ AD objects) or if someone objects to password hashes (which are not reversible so not really a valid objection in my opinion) being stored in Azure. All that is need for Hybrid is dirsync (+ password sync assuming you don’t want different passwords). ADFS gives you added complexity and a single point of failure unless you have L4 load balancers and multiple ADFS servers and ADFS proxy’s and for most small – medium business that is surely somewhat defeating the purpose of going cloud.

2.       Before running dirsync you should plan and check your on premises AD is ready. The most important thing is to ensure that the UPN’s for your objects have valid FQDN’s (e.g. no .local addresses). This tool will check AD for you: There was also talk that you should ensure that your on-premises AD password policy meets the minimum requirements of Azure’s password policy or you will have issues sync’ing passwords.

3.       Dirsync remediation tool. If you have jumped ahead and not checked out your AD and ended up dirsync’ing bad objects then this tool (idfix) is for fixing it:

4.       This: is good for setting up a proof of concept for a customer and then going live with it, it’s kind of a step by step deployment…

5.      You can setup a demo tenant with a load of pre-created data to demonstrate all the cool features of things like SkyDrive Pro and the new Office 365 suite, Excel for example does some really cool stuff which should get people seriously interested in upgrading to the latest Office suite. The only downside is it expires every 30 days so you have to keep setting it up again but it’s not hard and doesn’t take long. It even gives you a complete walk through of how to demo Office 365, although I would suggest you focus on bits that customers will find interesting rather than go through the whole thing. Login with your partner ID here

6.       Office 365 ProPlus application suite is licensed per user not per device, each user can install the Office 365 suite 5 times. This means it is not suitable for RDS, Citrix, hot desking etc. However, there is a concession on licensing for office 365 subscribers that allows you to use volume licensing versions of Office 2013 ProPlus at no extra cost. The only caveat here is that to use the volume license version you must buy at least one volume license key as Microsoft won’t give you one.

7.       For Hybrid deployments you need a Hybrid Exchange server, there was some confusion as to whether this could be setup on an existing Exchange server, the consensus seemed to be that you can but shouldn’t but this was something of a grey area. You do not need to license a 2013 Hybrid server so there is no cost (other than hardware resources) to build a 2013 Exchange server to use as your Hybrid, the Hybrid wizard is significantly improved on 2013 so is worth considering if you are otherwise on 2007 or 2010. The Hybrid 2013 server(s) must have all the roles although you can split the roles over multiple servers. The hybrid server does nothing except pass TLS encrypted mail between on premises and the cloud so load should be pretty minimal.

8.       Security between Hybrid and online servers. Kind of obvious but you can’t have things like hosted mail hygiene solutions or firewalls inspecting traffic between the Hybrid server and Office 365 servers or TLS won’t work. In fact you wouldn’t have 3rd party hosted mail hygiene full stop because anti-spam and AV is built into Office 365.

9.       You can now install dirsync on a DC but this is not supported and is only for non-production environments.

10.   In a hybrid environment delegation won’t work between mailboxes that are on Office 365 and mailboxes that are on-premises. So check for delegates and ensure mailboxes are moved together where delegation exists (this is also a problem with 2013 co-existence). Apparently Microsoft are intending to fix this but there is no ETA.

11.   There is no such thing as single sign on for Office 365 Outlook (doesn’t matter whether you have ADFS or not). SSO and ADFS seems to be something of a misnomer, there are certain things that can used forms based authentication (e.g. OWA) where SSO will be facilitated by ADFS for internal users but it is not ADFS as such that is doing the SSO. The short of it is that you simply will end up putting in your password more often. It can be cached in cookies, credential manager etc so should be fairly infrequent for users to get extra login prompts. Even for the parts of Office 365 that will get a kind of SSO with ADFS, bearing in mind that Outlook for example won’t benefit, it seems pretty hard to justify the extra resources and complexity required for ADFS.

Hope this helps clear up a few misconceptions about deploying Office 365, it certainly did for me.