Client Area · 0114 299 4050
View Services

Common issues in Microsoft Exchange 2013

Common issues in Microsoft Exchange 2013
Neil lends his expertise to some common issues in Exchange 2013 and how to resolve them

I recently installed and configured Microsoft Exchange 2013 for a client and came across a few issues along the way. Once I'd managed to resolve these I thought I would share the some thoughts on how to configure it to remove these issues in future.

I also wanted to talk about some of the new features and how to configure them, like the ability to import and export mailboxes from the new web-based Exchange Admin Center, also known as the Exchange Control Panel (ECP).

Throughout this blog I will be using the all-new web based Exchange Control Panel, and the Exchange Management Shell application to run some powershell commands.

The first issue is pretty simple to solve; that of the location of the Exchange database. By default it will install on the drive you install the OS onto. You can either specify otherwise or, if you realise a little too late, run this little command in the EMS to move it to a new location:

Move-DatabasePath "Mailbox Database 1" -EdbFilePath "D:\Exchange\Mailbox Database 1.edb" -LogFolderPath "D:\ExchangeLogs\Mailbox Database 1"

This command moves the Exchange database called "Mailbox Database 1" from its current location (which you do not need to enter) to the data drive, and also moves the log files to a separate folder on the data drive.

At this point you will be prompted to accept that you do indeed want to move the database, and will receive a warning that the database will be temporarily dismounted while it is being moved. If the database is empty and not being used you can say yes, knowing it will take seconds to move and nobody will be affected. Obviously in a live situation you may want to wait until a suitable time to do this!

Importing PSTs

Next I wanted to import some .PST files into the new Exchange accounts I had created and found that this option is not enabled by default. You can give import/export permission to administrators or a group of Exchange admins, or even a specific user within your organisation. I found the easiest way to do this was to create a new security group and add the users I wanted into this group. Once this was done I could give the import/export permission to this group.

In the ECP under the permissions section, I created a new admin role called "Import Export role". I then added the "Mailbox Import Export role", and added my required users to the members section.

 Exchange 2013 admin roles

Import Export role

When I went back to the recipients section, I could now select a mailbox and click the three dots next to the refresh icon, and in the dropdown list I could now see the extra options such as Import PST and Export to PST file which were not available to me beforehand.

Extra items on drop down menu

Great! So I can now start to import the PST files into the correct mailboxes.

The next issue however caused the PST file import to fail with an error relating to the size of messages within the PST exceeding the limit. By default the send and receive limit on the connectors is set to 10MB so any messages with large attachments may cause the import to fail as the import tool uses these connectors to effectively send the emails within the PST to the new mailbox.

I found it much easier to use the EMS to increase these limits as you can do it all from one place rather than searching through the ECP to find the right locations to make the changes. However you can use either method. This image shows the powershell command to set the limits of the "internet" connector to 50MB. The second image shows the command to change the send and receive limits for the transport role.

 Connector message size limits

Transport message size limits

This resolved the issue for most of my PST import requests however I had one troublesome PST that still failed to import. I identified a potential issue with the PST and ran a scan PST on it and tried again. It still failed. To get round this issue I found I could add a switch on the end of a powershell command to raise the limit of bad items the import will ignore before failing. If you raise this level, you also need to add another switch to say you accept there may be a large amount of data loss as you have allowed exchange to ignore a large number of bad items.

The command I used looks like this:

New-MailboxImportRequest -Mailbox "Administrator" -FilePath "\\SERVERNAME\\Outlook psts\Administrator.pst" -BadItemLimit 51 -AcceptLargeDataLoss

This command will import the administrator.pst file from the specified path into the mailbox named Administrator. It will ignore 51 bad items before failing and you agree that this may cause a large amount of data loss. Obviously you will need to check how much data has been imported and make an executive decision on whether this is usable or not.

Password prompts

My next issue was with users that had multiple Exchange accounts set up in Outlook 2010 so that they could send and receive mail from multiple accounts and the sent items would be stored in the correct mailboxes.

Every time the users opened Outlook they would be prompted for the credentials for each account which is obviously time consuming, and confusing for the users who would have to remember numerous passwords, causing a lot of frustration.

This issue is caused by the authentication methods used by virtual directories within Exchange. To stop the prompts, I logged onto the ECP and found the virtual directories tab listed under the "servers" option on the navigation panel, and added the basic authentication setting to the EWS (Default Web Site) directory.

In previous releases of Microsoft Exchange, basic authentication meant all credentials were sent in plain text. In this version SSL certificates are used to encrypt the credentials adding a level of security that was previously not available.

 Virtual directory settings

 Basic authentication

Another way to resolve this issue is to give the user full mailbox permissions so that they authenticate with their own username and password for all mailboxes. However, if you were to use the ECP to grant these permissions to a user, the mailbox will be added as an additional mailbox automatically, which will conflict with the separate Exchange account connected to the same mailbox, thus causing issues.

To give full mailbox permission to a user or group without the account automatically being added into Outlook, you will need this command:

Add-MailboxPermission -Identity "Shared Mailbox" -User "User 1" -AccessRights fullaccess -automapping:$false

Where "Shared Mailbox" is the mailbox you want to change the permissions of, and "User 1" is the user or group you want to give access to.

In the ECP you can delegate "Send as" permissions to any user that needs to send from any of their secondary Exchange accounts.

Scan to email

My next task was to configure a multifunction printer to scan to email but even though it could connect to the Exchange server it could not send mail. It would just say "waiting", and after a few attempts it would fail with a very vague "unable to send mail" message.

To combat this, I set up a receive connector specifically for the device. In the ECP I found the receive connectors tab under "mail flow", and created a new connector called "Scan to email".

On the "general" tab I could give it a name, enable the connector, and set the receive limits (as mentioned earlier you could set the limits of all your connectors in this way).

Then on the "security" tab I unchecked ALL forms of authentication and permission groups apart from Anonymous users. This would usually open up your Exchange server so that anyone could use it to send mail and possibly cause you to end up on blacklists for sending spam or large amounts of mail. To counter this, on the scoping tab I set the internal IP address of the scanner as the only address this connecter would accept mail from. I then set the port to 25 for SMTP. You can of course set 3 or 4 IPs or a range of IPs to allow all your devices to send through this connector.

 Scan to email connector

Free/Busy information

My next issue was with free/busy info.

When the users selected a room or resource to create a meeting, they were able to see if the room was free or busy, but could not see the details of the meeting or who had created it. This was not ideal as some meetings had been set up as recurring but didn't always take place, meaning that the room may in fact have been free to book.

To give the users permissions to view the full information I used the following command in the EMS:

Set-MailboxFolderPermission boardroom:\Calendar -User Default -AccessRights Reviewer

This gave default users reviewer rights to the calendar of the boardroom mailbox so that they could see the full information of the meeting, for instance who was in the meeting, and who created it.

You can check the permissions of a mailbox at any time as shown here.

 Mailbox permissions

Outlook Anywhere SSL

The final issue I had was with the Outlook Anywhere settings for users that might use their machines to remotely access email. I had already set my virtual directories up to use the same URL for internal and external access, and set up DNS on my server so that it would resolve internally. I had installed a wildcard SSL certificate (*.domain.com) and wanted to use this for authentication but every time I set the required proxy server certificate name and reopened outlook it would change it back to match the proxy server URL (remote.domain.com).

This meant that users would get a certificate error when opening Outlook, saying that the name on the certificate did not match the server name. In some cases Outlook would fail to connect at all!

To resolve this I had to set the OutlookProvider attribute on the Exchange server to reflect the wildcard SSL so that machines using the autodiscover service would be looking for the correct certificate name when authenticating.

In EMS I used the following command:

Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.domain.com

When I went back to check the Outlook Anywhere settings on the client machines, I found that this setting had been automatically updated and the certificate errors had stopped. All machines would now happily connect to Exchange remotely.

Mounting a database

A few days after configuring everything I have mentioned so far, I had a call to say no mail was being received, and for some reason when I checked the status of the database, it was dismounted.

When attempting to mount the database through the ECP I got a very generic failure message, so I used the following shell command to mount the database:

Mount-Database "Mailbox Database 12345678"

This worked perfectly and my client has been working happily ever since.

I hope this blog is of some use to anyone wanting to install and configure Microsoft Exchange 2013. Some of the issues and fixes found here may also apply to previous versions of Microsoft Exchange. 

< Back to Blog

Popular Posts:

Comments

Please leave a comment



Allowed tags: <b><i><br>



emergency it response: 0114 299 4050 View PAYG Options