Sembee Blog of Exchange MVP Simon Butler

If you are having problems with your Exchange server, you have a number of sources for assistance. 

You can Google for the problem, and in many cases this will bring up something that can assist you.

If you have a fairly specific problem though, you might need to actually explain it to someone to get assistance. For that you have two main sources. 

1. Microsoft Support - this is of course a chargeable solution. 

2. Peer to peer support. 

The second option is very popular and is where you can get assistance from some of the top Exchange experts. Exchange MVPs (like myself) post in peer to peer locations, as do some Microsoft employees. 

Where to find peer to peer support

With the demise of the Microsoft Newsgroups, peer to peer support pretty much comes in two forms. 

• Forums
• Email Lists

Email Lists

One of the most active email lists was hosted by Sunbelt Software, who were acquired by GFI. GFI have now announced the lists are going away, so the new list can be found at "My IT Forum" http://myitforum.com/myitforumwp/services/email-lists/  

Yahoo Groups also have email lists for each version of Exchange, however these appear to be very low traffic. 

Use an Outlook.com account or a public folder to store the list traffic - they can get very busy and by putting the content in to a separate place it will keep it from your main email. 

Forums

There are lots of forums where you can get support for Microsoft Exchange. 

Microsoft Technet

Exchange 2013: http://social.technet.microsoft.com/Forums/en-US/category/exchangeserver

Previous Versions: http://social.technet.microsoft.com/Forums/en-US/category/exchangeserverlegacy 

Very busy forums, which are monitored by Microsoft staff. However there are a lot categories therefore working out where to post can be a challenge. 

Experts Exchange

The Exchange section is very active and is one of the main places you will find me posting. Contrary to popular belief, you don't need to pay to either see the solutions or post a question. A free account can be created here: https://secure.experts-exchange.com/expertSignUp.jsp

Petri

Exchange 2000/2003: http://www.petri.co.il/forums/forumdisplay.php?f=12 

Exchange 2007/2010/2013: http://www.petri.co.il/forums/forumdisplay.php?f=36  

Another forum where you will find me posting, I also moderate the Exchange forums. Not quite as busy as some, but knowledgeable people post. 

Msexchange.org

http://forums.msexchange.org/ 

Another forum divided in to categories. 

There are other forums out there, but have very low traffic, which means your question may go unanswered. 

You can also find groups on Linked In, if you have an account there. 

More ways to get assistance can be found on my list of Exchange resources at http://exbpa.com/ 

SSL certificates are a constant source of pain for Exchange administrators. With Exchange 2007 and 2010 so heavily dependant on web services, getting SSL setup correctly is important for correct operation. 

A lot of SSL certificate deployment is now being done for mobile device support, and then you open a new issue - SSL certificate compatibility. 

Recently I found a large list of SSL certificate and client compatibility. 

It is from a Danish SSL reseller called FairSSL:

http://www.ssltest.net/compare/sar.php 

Most useful for mobile platform compatibility, the combinations it lists are significant. 

On the same site they also have a tool to verify that your SSL certificate is installed correctly. Most of the SSL vendors also provide this, but if you don't have the login details (perhaps because the certificate was just supplied to you) then it is a useful service to have:

http://www.ssltest.net/ 

With more SSL providers now using intermediate certificates to issue the certificates, rather than the root, getting the certificates installed correctly can mean the difference between SSL working and not. 

[ad]

An interesting little issue with a client's configuration caused a problem recently.

The problem only affected users off site using Outlook Anywhere. While they could get their email correctly, the availability service didn't. This stopped Out of the Office from working correctly unless OWA was used, or the end user was in the office.  

This particularly configuration uses a Client Access Server in a data centre, which proxies over a site to site VPN in to the main office where another CAS, plus the mailboxes are actually located. Therefore the issue had to be around a configuration difference between the two servers. 

Running 

get-clientaccesserver servername |fl 

on the server in the data centre and comparing it to the server in the main office, showed that the value for AutodiscoverSiteScope was populated with the AD site for the main office. This was because the server in the data centre had been built in that location initially and then moved. 

Removing that entry so it was blank resolved the issue:

Set-clientaccessserver servername -AutodiscoverSiteScope $null 

A five minute fix resolved an annoying problem for the end users. 

During a recent migration from Exchange 2007 to 2010 I found I was unable to remove the public folder store from the Exchange 2007 server. 

It was returning the following error when using remove-publicfolderdatabase or using EMC on Exchange 2007. 

Remove-PublicFolderDatabase : Object is read only because it was created by a future version of Exchange: 0.10 (14.0.100.0). Current supported version is 0.1 (8.0.535.0).

Obviously the Exchange 2010 server had touched the database in some way, probably due to the Offline Address Book migration. 

The fix was quite simple - remove it using the Exchange 2010 Exchange Management Shell. Can't use the GUI as the Exchange 2007 public folders do not appear in there.

Get-PublicFolderDatabase -Server EXCH2007 | Remove-PublicFolderDatabase

Where "Exch2007" is the name of the Exchange 2007 server. 

After removing the database I refreshed the GUI and was then able to drop the Storage Group and complete the removal of Exchange 2007. 

An increasing issue appears to be a certificate prompt being seen by Outlook 2007 and higher clients following the introduction of additional CAS servers, or new multiple role servers holding the CAS role. 

While this has been an issue for some time and well known to those running a multiple server environment, the increasing number of postings on forums about this problem has probably occurred as single Exchange 2007 servers start to get to end of life and people migrate to Exchange 2010. 

The cause of this is usually autodiscover. 

What is Happening

CAS Servers have a value called "AutoDiscoverServiceInternalUri". This is published in to the domain as a Service Connection Point (SCP) and is queried by Outlook 2007 and higher as part of the internal autodiscover process. It tells the client where to connect to for the account information. 

If you have multiple CAS servers then they will all be publishing this information to the domain, in effect overwriting each other. 

This command will show you the name and the value set on all Client Access Servers in the org:

Get-ClientAccessServer |select name,AutoDiscoverServiceInternalUri

The Resolution

There are two resolutions to this issue, depending on your setup, and future plans. 

1. The simple fix is to bring forward the introduction of the trusted SSL certificate and get it installed on to the new server. The value for "AutoDiscoverServiceInternalUri" should match one of the host names on the SSL certificate. Remember that most SSL providers will not allow multiple certificates with the same names on them to be issued, so you may have to get a new certificate issued to cover all servers with the CAS role. 
   
2. Set the value for AutoDiscoverServiceInternalUri to be the same on all CAS Servers. If this is a specific server name, rather than a generic name, then you will need to change that value on all servers if you remove that server from production. Alternatively you could ensure that autodiscover.example.com resolves internally on your network to the IP address of a CAS server, then set all CAS servers to use that value. Then when the servers are changed, all you need to do is update the DNS. If you have clients on your internal network which are not members of the domain, then you may well have already configured this. 

Multiple AD Sites

If you have your CAS servers in multiple AD sites, then you may well have to consider using site scope to control which server the clients will connect to. There are other things to consider if this is the best thing to do or not and this Technet article explains how to use Site Scope: http://technet.microsoft.com/en-us/library/aa997633(EXCHG.80).aspx

CAS Array

This is not related to the Exchange 2010 CAS Array function, and you shouldn't use the CAS array host name for this. The CAS array doesn't use HTTPS and also shouldn't be resolvable from outside. 

The default behaviour of Outlook with regards to sent items continues to come up on forums as an issue.

By default, when you send an email using the From field via your Send As permissions, the item you have sent goes in to your own Sent Items folder. This is because you sent it, not the person whose mailbox it was sent from. This can be useful from a tracking point of view (who sent the email).

However it may also be useful for the item to be stored in the Sent Items folder of the Shared Mailbox so that other users or even the mailbox owner can see what was sent.

How you achieve this depends on the version of Outlook that you are running. The version of Exchange doesn't matter.

For Outlook 2003 and 2007, a registry change is required, following the installation of an update. If you are keeping the machines up to date, then further updates should not be required.
These registry changes are outlined in the following articles:

Outlook 2007
http://support.microsoft.com/kb/972148
Requires Outlook 2007 Hotfix: 970944
http://support.microsoft.com/kb/970944/

Outlook 2003
http://support.microsoft.com/kb/953804/
Requires Outlook 2003 Hotfix: 953803
http://support.microsoft.com/kb/953803/

For older versions of Outlook, you will need to look at third party tools. The only one that I am aware of are the tools from Ivasoft: http://www.ivasoft.biz/

For OWA, you will need to use a server side tool, again the third party tools from the above site are the only ones that I am aware of - and support for latest version of Exchange isn't available.

For Outlook 2010, no registry change is required, you just need to add the mailbox in a different way.
Instead of adding the mailbox as an additional mailbox through the Properties of the primary mailbox, add the additional mailbox as an additional Account. That means going through the new Account wizard again. This feature also allows you to have connections to another mailbox in another Exchange forest at the same time - I have used this to migrate public folders (see http://blog.sembee.co.uk/post/Cross-Forest-Public-Folder-Migration.aspx)

However if you are using Outlook 2010, you should also be aware of the issues  in this KB article: http://support.microsoft.com/kb/2297543 (Performance problems when you try to access folders in a secondary mailbox in Outlook 2010).

(Late posting because I forgot to press publish).

During a recent mass migration from Exchange 2003 to Exchange 2010, I had a large number of mailboxes that appeared on the new server as the type "Linked".

Now while you can change the mailbox type between normal, shared and resource, it isn't supported to change it from Linked. The only fix is to disconnect the mailbox from the user and reconnect it. This of course has other consequences if not done with care, including breaking internal email replies to old messages that user sent.

I therefore went looking for the actual cause.

The most common cause is another account having the permission "Associated External Account". That is an Exchange 2003 permission, which I cannot find the equivalent of in Exchange 2007/2010. Therefore the only way I found to remove that permission was to move the mailbox back to the Exchange 2003 server. This allowed me to look at the mailbox permissions through ADUC and remove the permission. It should only be on the "Self". In this client's case I found it was allocated to a SID, so a broken account.

If you attempt to modify the permission while the mailbox is on Exchange 2007/2010 you will be unable to and will simply get an error message instead. 

After removing the permission, you can move the mailbox back and it shouldn't be linked.

Very occasionally you will get a mailbox where this does not work, when the drop and reconnect method needs to be used, or you might have a large number of mailboxes that are linked where moving them back is impractical. For those occasions, a script may well be more appropriate.

Fellow Exchange MVP Tony Murray has a PowerShell script to automate this, and it is available from this location:

http://www.open-a-socket.com/index.php/2010/08/30/powershell-script-to-bulk-convert-linked-mailboxes/

Anyone who has done a cross forest public folder migration will almost certainly be reliving their nightmares about it simply from reading the title.
I was just the same.

Extract the content to a PST file, either manually (selecting about 1000 items at a go) or by using a rule, move the PST file to a machine in the new forest, then import.

Slow, mind-numbing dull and therefore not the most fun part of a migration and always the bit that I don't look forward to. 

However a recent migration was done almost completely hands free. I moved almost 9gb of data in an afternoon, while I went to the cinema.

To do this, I took advantage of the new feature of Outlook 2010 that allows it to connect to two different Exchange organisations at the same time.

This allowed me to create a rule to move the content between the two public folders. Once the rule was set, I left it to get on with it. The speed wasn't great, but compared to moving it manually, it was a considerable time saver. After returning from cinema I was able to do more of the migration work, while I waited for the rule to finish.
Furthermore, by using multiple machines, I could move lots of large public folders at once. Once the process was completed, the rule was discarded.
Even before moving the data, when creating the new folders it was easy to setup the permissions as I could compare them side by side.

Where an item was corrupt and couldn't be moved, or the few items that didn't match the rule, I simply moved those items manually or deleted them. In most folders this was only a few hundred items at most.

You still can't copy and paste large numbers of items, as the problem with trying to copy/cut and paste more than about 1500 items is still in Outlook, but a rule effectively moves each item individually, so that isn't a problem.
For the folders with small number of items, a straight copy and paste works well.

I used the same procedure to move a stubborn mailbox which wouldn't move on the regular cross forest move mailbox procedure. Much faster than exporting the mailboxes out to PST file and then importing them. It also allowed me to identify the corrupt items and deal with them.

Even if you aren't deploying Outlook 2010 for your migration, it is worth downloading the trial for this feature alone. Then once the migration is complete, discard the trial software.

One of the most useful online tools to come out of Microsoft for the Exchange product is their testexchangeconnectivity site - or to give it's correct name - the Microsoft Exchange Remote Connectivity Analyzer (ExRCA). However the URL is a mouthful, and if you are typing it as often as I do, it is easy to make mistakes.

Therefore I have setup a short URL for it using our Exchange community site exbpa.com  - you can get to it via http://et.exbpa.com/

I was going to use te.exbpa.com (which also works) but I thought et would be easier to remember.

21st April 2011

An Updated and revised version of this article can be found on our main site here: http://exchange.sembee.info/2007/install/sbs2008ssl.asp

In recent months I seem to have spent longer with SBS deployments, rather than Exchange 2007 or 2010. Therefore I have had lots of time to get annoyed with how SBS 2008 works with SSL certificates.

Exchange 2007 is very dependant on SSL certificates, which is something I have posted about in the past. However throw in the customisations to IIS that SBS 2008 makes and it gets much harder.
The SBS team have attempted to simplify the process, but for most people they have actually made it worse.

The major problem with SBS 2008 and SSL certificates is twofold.
1. SBS 2008 presumes that your external DNS provider supports SRV records. Their DNS partners that are pushed in the wizard do of course, but most do not.
SRV records are one of the methods that Outlook 2007 can use for autodiscover. Autodiscover is connected to the availability service. Therefore that means if you are using Outlook Anywhere, without autodiscover working correctly, the client doesn't work.
It can also cause problems internally, but the wizard does actually make the required changes for that.

I can see why the SBS team used the SRV record method, as it allows a standard single name SSL certificate to be used - usually remote.example.com . The wizard then makes the requires changes to Exchange and the domain to allow this method to work correctly. Using a single name SSL certificate keeps the costs down, as anyone who has worked with SBS user will know - getting the typical customer to pay for a certificate can be difficult, particularly when there is a "free" certificate in the product.

The comments in this article from Sean Daniel clearly show the presumption of SRV records use. In my opinion this is a very poor decision from Microsoft, when the wizard could easily automatically enter the additional names that are required and generate the relevant request.
http://sbs.seandaniel.com/2009/02/installing-godaddy-standard-ssl.html

2. The second issue is that SBS 2008 sets up additional web sites and uses them for external traffic. If you install and enable the certificate in the usual way for Exchange 2007, then you break those sites. That causes a mess, which can be resolved, does make extra work.

However, it is possible to get the certificate in place, in a way that is acceptable to both Exchange 2007 and SBS 2008. Whatever you do, DO NOT use IIS to generate and manipulate the certificate.

Preparation Work

To ensure that you work with the common configuration for SBS 2008, some DNS entries need to be made on the internet facing DNS services (usually your DNS provider).
Specifically these are
remote.example.com and autodiscover.example.com

(where example.com is your domain after the @).

These should point to your public static external IP address. If you cannot use a static IP address, then use a dynamic DNS provider to setup a host. Then create a CNAME for each of the above hosts and point them to then dynamic DNS host name.

While you can use another host name instead of remote.example.com, but everything in SBS seems to be orientated towards that name. Therefore I usually also use that host name for the MX records for the server as well, and get the ISP to setup the reverse DNS (aka PTR) record.

Certificate Request Generation and Response Installation

To generate the request, follow my guide elsewhere on this blog: http://blog.sembee.co.uk/archive/2008/05/30/78.aspx
However, add the name "Sites" to the list of domains that you include. That makes the full list:

remote.example.com
autodiscover.example.com
server.domain.local (the server's internal FQDN)
server (the server's NETBIOS name)
sites

When you get the response back from your provider, continue to follow my blog article up to the point about installing the response. DO NOT use the enable-exchangecertificate command.

By using the Exchange Management Shell to do the request you do not put the current self generated certificate at risk, because the request and response doesn't touch it. The certificate is only changed later on in the process.

Activating the Certificate

Now this is where things get different to Exchange 2007 full product installation.
In the SBS Management Console, start the SSL certificate. Select the option to use an existing certificate. Your new UCC certificate with the additional names should be listed. Select it and then complete the wizard. SBS will install the certificate in to the web sites correctly for you.
You should then be able to browse to https ://remote.example.com/remote and use the full feature set.

You can verify the certificate is installed correctly by using the Fix my Network wizard, which shouldn't touch the certificate installation - or by running the SBS Best Practises tool. The link to that is on my list of Exchange resources at http://exbpa.com/

Conclusion

With care, you can deploy a commercial certificate on to SBS server, without breaking any of the functionality of the server. This provides a more professional looking deployment for everyone involved, and no need to tell users to ignore certificate prompts.