Tag Archives: Exchange

Exchange Mobile Device Issues

A user deleted and recreated their mobile account which landed their mobile device into quarantine but it was unable to be approved. Also, quarantined devices for users who have been deleted or disabled cannot be removed using the GUI.

The issue seems to be that there are two sets of data to keep track of mobile devices on the server. The device could not be approved, because it was already approved and was stuck in quarantine. Rejecting the device added it as an unapproved device for the user.

First I needed to delete some “zombie” devices. Step one was to set Powershell scope to the whole forest:
Set-AdServerSettings -ViewEntireForest $true

Then get a list of mobile devices:
get-mobiledevice |fl UserDisplayName,Guid,DeviceType

I then pick out the phone that I need to delete and remove it:
Remove-MobileDevice -Identity

For the next issue, I need to Get the User’s ID:
get-casmailbox |fl Identity

Then I need the device ID that I need to change (this will be the same Device ID in the management GUI for Exchange):
get-casmailbox -Identity |fl ActiveSyncBlockedDeviceIds,ActiveSyncAllowedDeviceIds

Then set delete/add the device to the Blocked or Allowed lists:
Set-CASMailbox -Identity -ActiveSyncBlockedDeviceIDs @{remove=”}
OR
Set-CASMailbox -Identity -ActiveSyncAllowedDeviceIDs @add=”}

Corrupt Exchange AutoComplete

So this has happened to me twice and I had forgotten how to fix (‘fix’) it from before so I’m writing it down here for when I inevitably forget again.

The symptom is that the user’s address autofill/AutoComplete within Outlook stops working. Since we run on a later version of Exchange this means that the autofill information that is stored on the server is corrupt (this post applies specifically to Outlook 2010/Exchange 2013). As far as I can tell the settings on the server are gone so the information has to be reconstructed, which for the user, is better than nothing. To do so I follow these easy steps:

  1. Download NK2Edit
  2. If you want a backup of the corrupt information, you can follow the steps here or backup the ‘DAT’ files (outlined in this post, though there seems to be a consensus that this won’t do the trick on Exchange where these files are always ‘pushed’ and never ‘pulled’)*.
  3. Clear out the existing AutoComplete (Step 4 here under “let me do this myself”)
  4. Open NK2Edit and make a new NK2 file with the same name as the Outlook profile (typically ‘Outlook’).
  5. Click the add button within NK2Edit and add every address that you can get your sticky fingers on, especially the addresses under ‘suggested contacts’.
  6. Exit Outlook and put the NK2 file in the proper path and go to Start->Run->outlook.exe /importnk2

Other suggestions:

  1. This article suggests the command ‘/CleanAutoCompleteCache’, but this would only seem to apply if there was a problem with the single Outlook install.
  2. One could always (*ugh*) restore the mailbox from an earlier time, etc., etc. I would reserve that course of action only for drastically desperate situations.

*I came by this tip (http://www.msoutlook.info/question/backup-and-restore-autocomplete) which says that you may be able to restore autocomplete entries with the cache file by using the MFCMAPI tool.  The caveat is added since the procedure basically involves hacking the mailbox so some risk is involved.

With Exchange 2013, you’re on your own

Many, many years ago I had a domain controller installed on a rather naughty IBM server.  This server, as it turned out later, had some bad firmware on the drives which would cause occasional system oddities such as blue screening, hanging on boot, etc.  I let it go for too long, but the issues were vague and infrequent; many a techie know the rut one can get into when it’s safer to leave well enough alone.  That line of thinking is always a catch-22 and the server’s issues finally came to a head when it crashed the right files and my domain controller no longer thought that it was a domain controller.

What about backups you say?  Well we had our handy-dandy untested disaster recovery backup from Arcserve, which turned out to require a special boot disk that needed to be made from the server in question before the disaster (this later turned out to be bogus anyway as I later found that even under the best lab circumstances I couldn’t get their worthless product to work).  I was in a pinch so I called Microsoft support and somehow, over the course of the night, they were able to get the trashed Active Directory operational again.  The call spanned between two shifts so the guy I talked to at the end of the call was not the same one from the beginning.

Compare that experience to my recent experience with my Exchange 2013 setup where, it appears, no one in the eastern hemisphere was given proper training on the issues that this product is prone to having.  No one calls back in time, despite the use of cut-rate help, and if your support rep has an end of shift they may abadon you until the next morning.  Don’t bother with web/phone support unless you’ve exhausted the list below.

  • First and foremost, Exchange 2013 as released was a beta product.  Cumulative update 1, made it seem like it was usable, but please be sure to install CU2 if you want a product that comes close to behaving!  Before installing CU2 the ‘RPC over HTTP’ function was sketchy and I would get prompted for authentication when making a new profile, external users would work while internal ones would not, and running tests would result in ‘500 http’ web server errors in OWA and ‘X-CasErrorCode: ServerLocatorError’ when running the connectivity tester.
  • After installing cumulative update 2 on two different servers, it failed to start both the transport service and the frontend transport service (while making sure to start ‘manual’ processes that we don’t use like unified messaging).
  • The new Exchange control panel is a marvel to behold, and crap at the same time (much like Microsoft’s whole product portfolio at this point in time).  If everything works it’s great, but when it comes time to set ‘internaluri’ and whatnot to the virtual directories it’s best to get familiar with the get/set functions for these in Powershell.
  • Please make a note that the ‘Microsoft Exchange Service Host’ service has a nasty habit of resetting/changing the RPC folder settings in IIS.  On one server it would change the backend RPC to point to the frontend folder and on another it would turn off all the SSL on the RPC folders.  Why does it do this?  No one knows, though Microsoft did tell me that this can be effectively managed if you go to the registry key ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator’ and set ‘PeriodicPollingMinutes’ to zero.  However, if the server reboots, be sure to double check these settings again.
  • Amateur mistake, but remember when migrating mailboxes keep in mind that it will eat up double the disk space of the source mailboxes until a backup can roll the logs off.  Please note that backing up with DPM 2010 apparently does not count as a backup.  (Also note that, for whatever reason, mailboxes get a 5-10% size boost when going from Exchange 2010 to 2013).
  • Setup will make the proper ‘receive’ connectors, but not the send connector.  When making it through the Exchange control panel, I had to uncheck ‘‘ so that my send connector would work properly.
  • Another note is that within IIS, if you are not able to access Exchange properly through Outlook (but Outlook Web Access works), then it might also be that you are missing the ‘Negotiate’ provider for Windows Authentication.  Just add/check it by right clicking on Windows Authentication under the virtual directories->Authentication applet and clicking advanced.
  • One site had issues with Outlook hanging on the new message notification and a general slowness in trying to do anything else.  Were it not for the niggling issues from the migration I might have turned on to the culprit sooner: Kaspersky.
  • Of course I wonder how many places still run their single Exchange server in-house.  I’d imagine that it’s getting to be a pretty lonely existence.  If this is your situation: migrating a single Exchange 2007/2010 server to Exchange 2013, I should point out an issue with the SSL certificate.  Chances are if you have one Exchange server, you have one, simple commercial SSL certificate as well, though even if you cheap out and use self-signing this issue still might apply.  The issue is that once the users are migrated, and you then migrate the certificate, the Outlook profiles will need to be rebuilt – for every user.  I am guessing that there are at least two possible work-arounds, though I haven’t tested them.  One is to get a certificate with a different name, this way Outlook knows that it’s a different server and to re-do it’s security settings.  Another idea is that it might be possible to migrate everyone to the new server, let Outlook catch the settings change (this part does work) and then move the certificate later (sketchy on how Outlook will behave here).  The main issue with this is remote e-mail support since the old server cannot proxy to the new one (I believe?).  Otherwise, without changing the profiles, end users will just get logon/credential prompts and not be able to access their e-mail.

Command Line Argument

Firing up the way-back machine, I recalled interfaces from Exchange versions past that would immediately return some nice data, such as mailbox size, item counts, etc.  I set out to try and recreate some of these interfaces, but it seemed that a lot of the coding examples were in C#, a language that I wasn’t very familiar with.

Undeterred, I went through some C# lessons and I now have what I hope is a decent “working IT guy’s” knowledge of it’s inner workings.  Unfortunately at this point, I can’t exactly remember what I was missing from the past Exchange interfaces that drove me to learn C# to begin with, apart from the table that had the mailbox sizes.

I eventually determined that the Powershell command that I needed was:

Get-MailboxStatistics -server <exchange server name>| Select-Object DisplayName, TotalItemSize, ItemCount,StorageLimitStatus,LastLogonTime | Out-GridView”

I figured my C# coding skills would have to apply to something else as I could just as easily put that line into a batch file! For some reason, though, launching the command from a batch file would open the ‘Grid View’, but it would close immediately, so back to C#

I had the program working fine on my desktop, and had it set to either ask for a server name, or accept a command line argument that would contain the server name. For reasons I still don’t fathom, the command line argument wouldn’t work on the Exchange server itself. I eventually had to change the code from:

if (args[0] != null)
ServerName = args[0];

to:

if (args.Length>0)
{
if (args[0] != null)
{
ServerName = args[0];

Which makes more sense, I guess, but I don’t know why the former only worked on the desktop unless there’s some variation of the .Net runtimes between the desktop and server in how they handle command line arguments?

Anyway, if you’d care for a little program that auto-launches this grid view, I’ve posted it here.  It includes the user’s display name, their mailbox size, the number of items, and if they’ve exceeded their quota.  You may need this note if you get an ‘index out of bound’ error due to the Powershell visual GUI elements not being installed (obviously you’ll need a 64 bit machine with the Exchange Powershell add-on installed).

Scanning to Email

I have a friend with a Toshiba ‘e-STUDIO3530C’, a pretty typical ‘mopier’ machine.  They use the scan-to-email fairly extensively, but it started giving them issues recently where the scanned document would appear to go off to no where.  After checking the logs on the Exchange 2010 server, it turned out that the ‘scan’ e-mails were being caught up in the IMF/spam filter that comes packed with Exchange.  Scans were either going to the ‘junk e-mail’ folder, the quarantine e-mail box, or rejected outright (in which case an error would appear on the scanner).

After browsing around it turned out that the best workaround was to have the mopier sign-in to send the message since authenticated users were automatically white listed (indeed, the only white listing that the built in spam scanner appears to offer).  Luckily we already had secure SMTP authentication set up on the Exchange server so that users could send e-mail with their phones, but it still took a little experimenting to get the correct settings on the Toshiba, and these settings on the ‘SMTP client’ appeared to do the trick:

Obviously a dedicated user account will need to be created for the scanner and the appropriate information changed for your own purposes.