PowerShell script to find all Active Sync devices on an Exchange 2010 server that haven’t synced in a specified amount of time

I published my 1st Powershell script to Technet’s Script repository and Poshcode.org. You can grab it here and below are the details of the script straight from the help file:

.SYNOPSIS
Get-InactiveActiveSyncDevices pulls all user mailboxes with an Active Sync partnership and then selects the Active Sync devices that haven't synced in the specified period. These devices are sorted in ascending order and placed in a HTML table which is emailed to the specified user using a specified reply to address and SMTP server
PLEASE TEST BEFORE RUNNING THIS SCRIPT IN PRODUCTION
.DESCRIPTION
The script 1st checks to see if Implicit remoting is needed to load the required PSsnapin (Microsoft.Exchange.Management.PowerShell.E2010), this is done by seeing it the $ExchangeConnectionUri variable does not have a $NULL value. If it contains a URI then create a new PSsession using the current credentials and import the session. If Implict remoting isn't needed then verify that the required PSsnapin (Microsoft.Exchange.Management.PowerShell.E2010) is loaded and if not try to load it locally. Then  Get-InactiveActiveSyncDevices uses Get-CasMailbox to pull all the user mailboxes (Not Discovery or CAS mailboxes) with Active Sync device partnerships and saves them to a variable called $ActiveSyncMailboxes. It then walks through each mailbox and uses Get-ActiveSyncDeviceStatistics to pull DeviceType, DeviceUserAgent, DeviceID, LastSyncAttemptTime, LastSuccessSync for each mailbox’s separate Active Sync device partnership and puts these properties in addition to the full name associated with the mailbox into a hashtable called $UserActiveSyncStats. The reason why Get- ActiveSyncDeviceStatistics isn’t used exclusively is because it does not have a property that stores just the name of the user who owns the Active Sync device, only a full Active Directory path to the Active Sync device. This hash table is used to create a custom PowerShell Object which is then added to $ActiveSyncDeviceList. A variable called $MatchingActiveSyncDevices holds all the Active Sync devices in $ActiveSyncDeviceList that haven’t synced to the Exchanger server in less than or equal to the number of hours specified in $HourInterval . $MatchingActiveSyncDevices is then checked to see if it’s an empty array or not. If it contains items an HTML header is created to format the table for the HTML email report and saved in a variable called $HTMLHeader . Then The Body of the email contains all of the criteria matching Active Sync devices from $MatchingActiveSyncDevices in ascending order which is converted to HTML using the HTML header information created earlier in $HTMLHeader. Otherwise a the body contains a message stating that no devices matched the given criteria.. An Email is then sent out to the user specified in $to from the address specified in $from using the email server specified in $SmtpServer. The body is generated from the sorted Active Synce Devices in $ActiveSyncDeviceList.

 

Posted in Exchange 2010, PowerShell | Leave a comment

Multiple Exchange accounts in Outlook 2010 and 2013

We have added a lot of new email domains at my company recently and one most common request from our users is to work with multiple Exchange mailboxes within Outlook 2010. This would normally be accomplished by giving the user full access to whatever additional mailbox they need access to. But this method had some drawbacks for our users, mainly:

  • The user has to manually select the outgoing  email address of another mailbox they had full access to if they want to send as that account
    • The preferred behavior is that when they select the mail box from the Outlook tree and create a new email it will default to the outgoing address for that mailbox. This is not the behavior when granted full access to a mailbox, instead the outgoing email will always default to the primary Exchange account.
  • If the user requires separate signatures for each additional mailbox they have to manually specify them since the signature used will be the one for the main Exchange account. While you can create multiple signatures you can only attach one signature each for new email and reply to the main Exchange account and not the additional mailboxes the user was granted access to.

These might not seem like huge issues, but when these additional mailboxes are treated as if they came from separate companies it turn into a huge issue when a user accidentally sends an email intended for a client working with Company A with the outgoing email and signature from Company B. So in searching for a solution I came across this Microsoft Article detailing how to carry out adding multiple Exchange accounts to an Outlook profile. The problem is that it requires volume licenses of Office 2010 and a fairly complicated process to a get the additional accounts added. All the office licenses at my company are Medialess License Kits (MLK) so that ruled out this method. Originally it appears that the ability to add multiple accounts existed in the preview of Outlook 2010, but the method describe in the article no longer worked. And since there was an article detailing the process for retail release I assumed this feature was dropped. When the Office 2013 preview came out one of the 1st things I did was test its ability to add multiple accounts and surprisingly it worked! All I need to do was:

  1. After adding the first account in Outlook 2013 go to the File Tab.
  2. Under Info click on the +Add Account button
  3. From there fill in the info for the 2nd Exchange Account and it will be added to your Account Tree

This method allowed me to address the issues my users were having with managing additional mailboxes and didn’t require the user to have full access granted to the mailbox. Wondering if this worked in Outlook 2010 as well, I tried it and delighted it worked despite the documentation from Microsoft detailing a much more involved process to do so. I have since tested it up to 3 different Exchange accounts on the same Exchange server with no issues. I’m not sure what the limit is but I assume it might be 3 accounts per Outlook profile, like originally specified in the preview build of Outlook 2010.  

 

Posted in Exchange 2010, Outlook | Leave a comment

Make sure your Exchange 2003 server is fully removed before raising your AD Domain Functional Level

Though we completed our Exchange 2010 migration over a year ago we still kept our Exchange 2003 server around due to some hard-coded references in internally developed apps. Once those were taken care of we shutdown our Exchange 2003 server for a few months to make sure nothing else was still referencing it. After 6 months we decided it was safe to remove it from the domain and we used the following TechNet article as a guide. Now that Exchange 2003 was gone and after upgrading some other services that were dependent on a 2003 Native Domain Functional level we decided raise the level to 2008 R2. But immediately after doing so our Exchange 2010 server started locking up every 24-36 hours. We tried restarting the Exchange services during the lock up but only a reboot would fix the issue.

When reviewing the event log on the Exchange 2010 server it appears that it could not reach either of our domain controllers (DC01 and DC02), both of which held the Global Catalog server role. After multiple attempts to reach a DC or a GC the Exchange services would shut down causing all client protocols to go down with it. The most prevalent event log entry was as follows:

Log Name:      Application
Source:        MSExchange Autodiscover
Date:          8/2/2012 6:27:01 PM
Event ID:      1
Task Category: Web
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EX2010.company.net
Description:
Unhandled Exception "Could not find any available Global Catalog in forest company.net."

Other events that appeared related to the problem as are as follows:

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          8/2/2012 6:18:26 PM
Event ID:      5011
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      EX2010.company.net
Description:
A process serving application pool 'MSExchangeSyncAppPool' suffered a fatal communication error with the Windows Process Activation Service. The process id was '4976'. The data field contains the error number.
Log Name:      Application
Source:        MSExchange ADAccess
Date:          8/2/2012 6:29:03 PM
Event ID:      2103
Task Category: Topology
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EX2010.company.net
Description:
Process MAD.EXE (PID=5820). All Global Catalog Servers in forest DC=company,DC=net are not responding:
DC01.company.net
DC02.company.net
Log Name:      Application
Source:        MSExchangeTransport
Date:          8/2/2012 1:13:32 PM
Event ID:      5020
Task Category: Routing
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      EX2010.company.net
Description:
The topology doesn’t contain a route to Exchange 2000 server or Exchange 2003 EX2003.company.com in Routing Group CN=First Routing Group,CN=Routing Groups,CN=First Administrative Group,CN=Administrative Groups,CN=Email,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=net in routing tables with the timestamp 8/2/2012 5:13:32 PM DC02.company.net
Log Name:      Application
Source:        MSExchangeTransport
Date:          8/2/2012 1:13:32 PM
Event ID:      5006
Task Category: Routing
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      EX2010.company.net
Description:
Cannot find route to Mailbox Server CN=EX2003,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Email,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=net CN=Test,CN=First Storage Group (EX2003),CN=InformationStore,CN=EX2003,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Email,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=net in routing tables with timestamp 8/2/2012 5:13:32 PM. Recipients will not be routed to this store
Log Name:      Application
Source:        MSExchangeApplicationLog
Date:          8/1/2012 1:10:42 PM
Event ID:      9106
Task Category: ServicePicker
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EX2010.company.net
Description:
Service MSExchangeMailSubmission. Exchange topology discovery encountered an exception. Microsoft.Exchange.Data.Directory.ADTransientException: Could not find any available Domain Controller
Log Name:      Application
Source:        MSExchange ADAccess
Date:          8/1/2012 12:59:24 PM
Event ID:      2501
Task Category: General
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EX2010.company.net
Description:
Process MSEXCHANGEADTOPOLOGY (PID=1520). The site monitor API was unable to verify the site name for this Exchange computer – Call=HrSearch Error code=80040934. Make sure that Exchange server is correctly registered on the DNS server

At first glance the issues appeared AD related, but there were no obvious issues with the domain controllers or any other services relying on AD. The only recent major AD change was raising the domain functional level. Knowing that Exchange 2003 and back cannot function when the domain functional level is higher than 2003 Native, the entries referencing our decommissioned Exchange 2003 server (EX2003) seemed to be the root cause. In searching the web for answers we stumbled across a TechNet article that lead us to the references to EX2003 in Active Directory Sites and Services under Services -> Email -> Administrative Groups –> First Administrative Group. Which needed to be deleted:

  • \Email\Administrative Groups\First Administrative Group\Servers\
  • \Email\Administrative Groups\First Administrative Group\Routing Groups\First Routing Group\
  • \Email\Administrative Groups\First Administrative Group\Folder Hierarchies\Public Folders\

The actual removal was done in ADSI edit, which correlated to the following sections:

  • CN=Configuration,DC=company,DC=NET\CN=Services\CN=Microsoft Exchange\CN=Email\CN=Administrative Groups\CN=First Administrative Group\Cn=Servers\
  • CN=Configuration,DC=company,DC=NET\CN=Services\CN=Microsoft Exchange\CN=Email\CN=Administrative Groups\ CN=First Administrative Group\CN=Routing Groups\CN=First Routing Group\
  • CN=Configuration,DC=company,DC=NET\CN=Services\CN=Microsoft Exchange\CN=Email\CN=Administrative Groups\CN=First Administrative Group\CN=Folder Hierarchies\Public Folders\

Once removed the issue ceased!

When I discussed the issue at the Philly Exchange User Group, resident Exchange Master Bhargav Shukla mentioned that if I had used the Exchange 2010 Deployment assistant it would have had a section detailing how to properly remove Exchange 2003 in my environment.

 

Posted in Active Directory, Exchange 2003, Exchange 2010, W2K8R2 | Leave a comment

How to change and then resume a failed New-MailboxImportRequest In Exchange 2010

Recently I had to import a handful of PST files into a our Exchange 2010 server using the New-MailboxImportRequest cmdlet, and did so without setting the -baditemlimit parameter. During the import one of the files threw an error. Despite the discoverability of PowerShell, I couldn’t quickly figure out how to restart the import with a newly specified bad item limit. Obviously I didn’t want restart the import from beginning with a bad item limit specified, since that would create duplicate items at the destination mailbox.  And the Resume-MailboxImportRequest cmdlet did not allow you to change the settings of a failed import.  After some searching I came across a TechNet article showing how to do so, but since the information was hard to find via a Google/Bing search I’d figure I’d summarize it.

Once you have a failed mailbox import (the same holds true for exports) you can change the original request by piping it from Get-MailboximportRequest. For example, to set a bad Item limit to 50 on all failed requests.

Get-MailboxImportRequest -Status Failed | Set-MailboxImportRequest -BadItemLimit 50

To hit a specific request you can refer to it by name. By default, import requests are named <alias>\MailboxImportX (where X = 0–9). You could have specified a name for the import beforehand and use that to reference the failed mailbox in question, but I didn’t and this was the only failed mailbox. But if needed to I could have used :

Get-MailboxImportRequest -Identity USERALIAS\MailboxImportX | Set-MailboxImportRequest -BadItemLimit 50

If you can’t find the Identity you could always pipe all the failed requests into a formatted table and filter for Identity and Name property to make it easier to find the failed import in question:

Get-MailboxImportRequest -Status Failed | FT name,identity

Paul Cunningham has an interesting technique to get the Import identity over at his excellent Exchange blog : ExchangeserverPro.com . Basically you pull the user name using the get-user cmdlet, saving it as a variable, and then passing it to Get-MailboxExportRequest’s -identity parameter but with the .dn suffix. For example:

$User = get-user Jdoe
Get-MailboxExportRequest -identity $User.dn

So back to the rectifying the failed import: now that you have changed the request and set a larger bad item limit you can then resume all failed requests by:

Get-MailboxImportRequest -Status Failed | Resume-MailboxImportRequest

Or a particular failed mailbox import by:

Get-MailboxImportRequest -Identity USERALIAS\MailboxImportX | Resume-MailboxImportRequest

So what if you wanted to know what issue was causing the failure?  You can do so by using the Get-MailboxImportRequestStatistics with the -IncludeReport parameter . You’ll want to output the report to a text file since it will contain a lot of info that will be much easier to search in a text file as opposed to the console screen. Building off my previous example the command would be:

Get-MailboxImportRequest -Identity USERALIAS\MailboxImportX | Get-MailboxImportRequestStatistics -IncludeReport | FL > C:\FILEPATH\report.txt

You can review the exported text file for exact email(s) that caused the import to fail.

Posted in Exchange, Exchange 2003, Exchange 2010, PowerShell | Tagged as: , , , | Leave a comment

Exchange 2010 mailboxes inherit IMAP folder views and attributes if imported from a PST dump of an IMAP account

I recently had to migrate 9 IMAP accounts from GoDaddy to our Exchange 2010 server. Since GoDaddy does not offer export services and it was only 9 accounts we decided to use a handful of Outlook profiles to connect to the GoDaddy IMAP accounts and pull down a full copy of the mailboxes. The exact process we used is as follows:

  1. Use Outlook to connect to the IMAP accounts in question and pull down a full copy of the mailbox. You may run into issues accessing multiple large IMAP accounts from 1 Outlook profile. In my experience 5-10 accounts per profile should be ok.
    1. By default Outlook will only pull down the headers of IMAP messages, so you will need to instruct Outlook to do a full sync
    2. This is done under the Send/Receive Ribbon Tab -> Send & Receive Section -> Send/Receive Groups -> Define Send/Receive Groups…
    1. In the Send/Receive Groups window, highlight All Accounts and <click> the Edit…button
    1. Under the Accounts section make sure to highlight the IMAP account in question, and in the section labeled Account Options <select> one folder’s check box. Then <select> the radio button for Download complete item including attachments. Finally <left click> on the same folder and you should see an option to select and apply the same item to all folders with in this IMAP account. Repeat for each IMAP account
    1. Now perform a send/receive and wait for the all the messages to come down
  1. Since Outlook creates a PST file for each synced IMAP account (C:\Users\ACCOUNT\AppData\Local\Microsoft\Outlook) they can be used to directly import the mailbox into an Exchange account
  2. On my Exchange server I created 3 empty accounts (the reaming 6 became distribution groups) and used the following PowerShell command to import each PST into the corresponding empty exchange account
    1. New-MailboxImportRequest –Mailbox USERNAME –FilePath \\NETWORK\PATH\OF\IMAP.PST
    1. You also create a script to pull them all in at once, here’s an example of one way to do it if the PST file names match the user name
      1. Dir \\NETWORK\PATH\OF\*.PST | %{New-MailboxImportRequest –Name ImportOfPst –BatchName ImportPstFiles –Mailbox $_.BaseName –FilePath $_.FullName}

In our case these imported mailboxes belonged to a small consulting company that was purchased by my company. The users getting these email boxes already had accounts on our Exchange 2010 server and these imported accounts would be used to continue any business correspondences still associated with the old company.

So we gave the user’s send as and full access to their imported accounts and let auto-map do its magic. The issue we ran into was that while they could see the imported mailbox all new emails did not show up even though the unread count was increasing. When we checked via EWS, Active Sync, and Outlook Web Access the new items were visible.

After some poking around we noticed that while the folders and mail items were imported into an Exchange mail box, they retained the folder views associated with an IMAP account. The default view  of an IMAP account is to Hide Messages Marked for Deletion, but what it actually does is filter all the messages with the IMAP status of Unmarked.

The idea is to hide any IMAP messages marked for deletion that haven’t synced up with the IMAP server. Since Exchange messages do not have this field they would not show up with this filter applied. If the view is changed to IMAP Messages, which applies no filter, then all the messages show up. You can even apply this view to all the other mail folders. But a more elegant solution would be to remove the views all together, especially if you have hundreds of mailboxes having the same issue.

There are two ways I found to do this, one is a manual process that can only correct 1 folder at a time. The other is intended to correct mailboxes by the batch, but can also be applied to 1 mailbox

First method (Manually change each folder in a mailbox)

Using MFCMAPI you can change each email folder attribute from an IMAP designation (IPF.Imap) to an Exchange designation (IPF.note). MFCMAPI requires you to have access to the mailbox in question and a mail profile setup to access it (you can create one on the 1st run of the program). So you can either run the application from the user’s profile or a profile with access to the account:

  1. Start the program and login to your mail profile by going to Session -> Logon and select the profile that has access to the mailbox you need to edit. Once connected highlight that mailbox, <left click> and select Open Storefrom the drop down menu
  1. Once in the store navigate to the Top of the Information store. Depending on if this is mailbox is the default for the profile or added to it (via the Full Accesspermission) the folder tree is slightly different
    1. Default for profile : IPM_SUBTREE
    1. Secondary : Root Container -> Top of Information Store
  1. Now highlight the mail folder in question and look for the Property named PR_CONTAINER_CLASS, PR_CONTAINER_CLASS_A, ptagContainerClass and <right click> and select Edit Property… from the drop down menu
  1. From here you can edit the ANSI entry, which you’ll want to change from IPF.Imap to IPF.Note. Then <click> the OKbutton
  1. Repeat for all the mail folders in the container and exit the program when you are done.

Second method (“Find and Replace” batch method)

You’ll need a program from Microsoft called EXFolders, which you will install and run from the Exchange server (see the readme instructions included in the download). The instructions on using this program have been re-purposed form the following TechNet post answer provided by Kevinrk:

  1. Run EXFolders directly from the Exchange Bin folder
  1. Go to File -> Connectand fill the following fields:
    1. Type : Mailboxes
    1. Connect by : Database
    2. Global Catalog Server : Select your GC
    3. Databases : Select the Mailbox Database you want to work on
  1. Now select either the entire Mailbox Database or an individual mailbox you want to correct and select Tools -> Custom Bulk Operation.
  1. In the window labeled Custom Bulk Operation look for the section labeled Overall Filter and enter in the following string to make sure that only the mail folder container class is changed :
    • (&(0x361300iE=IPF.Imap))
  1. Under the section labeled Operations <click> the Add button and then select Other folder properties in the Operation Typewindow
  1. In the Folder properties operation window set the following options
    1. Action : Modify
    1. Property : PR_CONTAINER_CLASS : 0x3613001E
    1. Value : IPF.Note
  1. Once those options are set the Add button and then the OKbutton
  1. When you’re back to the Custom Bulk Operation window <click> OK to run the bulk operation. From here Exfolders will walk through the mailbox container(s) and change each instance of the PR_CONTAINER_CLASS from IPF.Imap to IPF.note

What’s next?

For either method you should have the user restart Outlook to make sure the changes take place. In some cases the IMAP views persisted and I had to reset the user’s views in Outlook (outlook.exe /cleanviews).

Posted in Email, Exchange 2010, IMAP, Outlook | 1 Comment

How to quickly disable account access in AD and Exchange 2010

While testing the feasibility of a Bring Your Own Device policy with Exchange 2010 Active Sync we noticed some odd behavior with disabled accounts.

One of the policies we decided on was that during an employee termination we would disable sending and receiving from an ActiveSync device before we removed Active Sync or wiped the device. The idea was that this would give a terminated employee time to make any personal phone calls before handing their personal device over to IT so we can remove the ActiveSync account. If they refused to hand it over we would wipe the device instead.

In testing we originally thought it would be enough to disable the AD account and reset it’s password to force propagation of the account throughout the forest. To our surprise though the disabled account could no longer access network resources it could still send and receive emails via Active Sync. Furthermore the account could also login into Outlook Web Access on both the old and new password. This behavior could sometimes last for hours!

After some research and a little help from the TechNet Community I found that the behavior stems from cached access tokens in IIS. Since both OWA and ActiveSync (also EWS) use IIS, which will cache access tokens for up to 15.  In my environment (and a few others) the cached tokens last for a few hours so I’m not sure what other factors are at play in keeping it alive longer then the 15 Minutes interval. One way to rest the token it is to restart IIS, but that is a little extreme as it will flush out all access tokens and active connections.

One of the various methods mentioned in the TechNet forums was setting the Allowed Recipients to 0:

Set-Mailbox -Identity "John Smith" -RecipientLimits 0

Obviously this allows the user to still access OWA, ActiveSync, and address books; but it stops them from sending any nasty emails through their disabled account after the fact. I also tried setting the Storage Quota to 0 for sending messages but that didn’t seem to apply in a timely fashion (15 mins). Setting the recipient account was almost instantaneous and works during an OWA session

I then tried to see if I could force a IIS Token refresh by changing the password
of a disabled account and then logging in with the new password. This had the strange side effect of caching 2 IIS tokens, one that worked with the old password and one that worked with the new one!

Over all the best method was to disable OWA and ActiveSync on the user account:

Set-CASMailbox-Identity "John Smith" -OWAEnabled:$False
 Set-CASMailbox-Identity "John Smith" -ActiveSyncEnabled:$False

This worked within 5 minutes and successfully locked out the account from both services.

 

Posted in Active Directory, Exchange 2010, Windows | Leave a comment

How moving your Default Domain Policy from the default location can lead to trouble

At my company we recently decided to change our password policy by increasing the password age to a year but doubling the length. So we planned to change the password age via Group Policy so that everyone would have to change their password by the 2nd week of January. Once everyone had changed their password we would push the age to 365 days. But try as we might the policies in our Default Domain Policy just wouldn’t take.

In trouble shooting we decided to use the Group Policy Results in the Group Policy Management Console. Oddly enough it showed that the changes were applied to the computers we tested against. At this point we thought maybe something was blocking Group Policy updates. So we used SPECOPS: GPOUPDATE utility to do a batch run of the gpoupdate /force command on the Active Directory OU that house our client PC’s. So we used the following power shell command from the Quest ActiveRoles Management Shell for Active Directory to find out the password expiration date of a few users who were properly getting our GPO’s:

Get-XADUserPasswordExpirationDate USERNAME

What we noticed was that their expiration date was still reflecting the old policy. So we decided to see if we could use PowerShell to edit the Default Domain Password Policy, and you can! So we ran the following command to get what PowerShell was reporting as the Default Domain Password Policy

Get-ADDefaultDomainPasswordPolicy

The output confirmed that though we modified the Default Domain Password Policy that the Group Policy was still retaining the old settings. At this point I was baffled, that is until I took a hard look at the Group Policy Management Console and noticed something blaringly obvious. The Default Domain Policy was not at the root of the domain but at the root of the OU we created for our office location. Once I moved the Default Domain Policy to the root of the domain and re-ran the command I saw the new settings take effect. Which is similar to how a PC will keep the last applied GPO settings when disjoined from a domain, the root of our domain retained the last applied GPO settings applied at the root level after the Default Domain Policy was removed.

This is also when I ran into another head slapping obvious moment. After the policy was moved to the proper location and was reapplied to the OU that our client computers were located in, the updated password policy still wasn’t being applied to all our users. This is because all users authenticate to a domain controller and that is where the policy takes effect, not at the client PC. Once applied we were able to check the password age of a few user accounts and see that the new settings did take effect

So the take away

  1. The Default Domain Policy must always be at the root of the domain
  2. If possible avoid using the Default Domain Policy all together and use separate polices to push down settings.
  3. Since domain users authenticate against domain controllers, password policy settings must be applied to the domain controller and not the client PC’s

 

Posted in Active Directory, Group Policy, Windows | Leave a comment

How to force OSX using Active Directory authentication to un-cache a mobile account’s username when it is changed in Active Directory

One of the situations we deal with a lot at my company is name changes due to marriages/domestic partnerships. Recently we had to perform a name change for one of our Mac users. This entails changing the following in Active Directory among other things:

  • Common Name (e.g. John Doe
  • Display Name (e.g John Doe)
  • samAccountName (e.g. jdoe)
  • userPrincipalName (e.g. jdoe@domain.net)

What we noticed is that our Active Directory bound macs won’t update the changed username of an account if it is set up as a mobile account in OSX. A mobile account allows offline logins of network accounts by caching login credentials and is turned off by default. From what I can tell this is due to the fact that once the mobile account caches the AD login information it doesn’t change it. This results in the user not being able to login in under either the old or new username on a Mac in which the user has logged into with a mobile account before the name change. Any new logins/mobile account creations work fine on any other AD bound Mac. After some research this is the best method we can across to force this change:

  1. Enable the root account if it is not already enabled
    1. In 10.5-10.7 open the “Directory Utility” either from System\Library\CoreServices or System Preferences -> Accounts -> Login Options -> Edit -> Open Directory Utility
    2. From the “edit” menu choose “Enable Root User”
    3. Enter in the a password for the root account
  2. Log out and login as root
  3. Once logged in turn on hidden files from the terminal
    1. defaults write com.apple.finder AppleShowAllFiles true/false
    2. killall Finder
  4. Browse to /var/db/dslocal/nodes/Default/users
  5. Look for the plist file associated with the old user account
    1. Make a copy on the desktop just to be safe
    2. Rename the file to match the new user name
    3. Do a find/replace to change the user name
    4. Save the plist file
  6. Go to the Users folder and update the name of the home folder
  7. From the terminal run the following command to verify that the new plist file is recognized
    1. Dscl . list users
    2. If not then double-check the plist file name
  8. Log out and then login under the new account name and verify everything works.
    1. You may also need to reset the Keychain as well.
  9. Go back to the “Directory Utility” and disable the root account
Posted in Active Directory, OSX | Tagged as: | 2 Comments

Take care with SAN Certificates in Exchange 2010 when Outlook Anywhere is enabled with PC’s Running XP and Vista

The last pain point of our Exchange 2003 to Exchange 2010 upgrade was getting Outlook Anywhere working with our XP clients, the cause of which was due to my inexperience with security certificates.

When we originally reviewed our requirements for Exchange 2010 we decided to go with a 20 slot Subject Alternative Name (SAN) Security Certificate. The reason we needed so many slots was due to the various outgoing domains we wanted to support. Also I was under the wrong assumption that I could use this certificate for other non-Exchange purposes, which you can’t.

When picking the Common name (CN) we decided to go with the root domain of our main company. So the final outcome of our SAN certificate was:

Common Name: MainCompany.com
Subject Alterative Names

    • Mail.MainCompany.com
    • Webmail.MainCompany.com
    • Autodiscover.MainCompany.com
    • Legacy.MainCompany.com
    • Mail.SecondCompany.edu
    • Webmail.SecondCompany.edu
    • AutoDiscover.SecondCompany.edu
    • Legacy.SecondCompany.edu
    • Mail.ThirdCompay.net
    • Webmail.ThirdCompay.net
    • AutoDiscover.ThirdCompay.net
    • Legacy.ThirdCompay.net
    • SecondCompay.edu
    • ThirdCompany.com
    • Maseradedomain1.com
    • Maseradedomain2.com
    • Maseradedomain3.com

This certificate functioned as needed until we decided to roll out Outlook Anywhere a few months into our upgrade. What we noticed is that our XP PCs running Outlook 2007 & 2010 couldn’t connect to our Exchange 2010 server using Outlook Anywhere. Our Vista PCs running Outlook 2007 and Windows 7 PCs running Outlook 2010 had no problem using Outlook Anywhere. When we checked the Exchange Remote Connectivity Analyzer we didn’t see any glaring issues. After playing with various Outlook Anywhere settings and failing we found was that XP, and Vista clients below SP1, can only read the CN on the and not the Alternative names on a SAN Cert. This normally wouldn’t be a problem if our CN could point to an Exchange server hosting the Client Access Server (CAS) role. This can be done be specifying the CN in the MSSTD, but since we used our root domain of our main common as the common name that wouldn’t help us.

Our only option would be to change the CN on our SAN cert. In order to do so the certificate needed to be revoked and then create a new certificate with the proper CN. Most Certificate Authorities will let you change the CN up to 30 days after the purchase date. But since we didn’t roll out Outlook Anywhere until a few months into out Exchange 2010 Upgrade we had to buy a new SAN certificate all together. So this time we made sure the CN was the external address of our CAS server, which in our case was also our Mailbox and Hub Transport as well. Since our company mailboxes are now fully migrated off Exchange 2003 we no longer need the legacy domains, so a 15 slot SAN cert was purchased this time

Common Name: mail.MainCompany.com
Subject Alterative Names

    • Webmail.MainCompany.com
    • Autodiscover.MainCompany.com
    • Mail.SecondCompany.edu
    • Webmail.SecondCompany.edu
    • AutoDiscover.SecondCompany.edu
    • Mail.ThirdCompay.net
    • Webmail.ThirdCompay.net
    • AutoDiscover.ThirdCompay.net
    • MainCompany.com
    • SecondCompay.edu
    • ThirdCompany.com
    • Maseradedomain1.com
    • Maseradedomain2.com
    • Maseradedomain3.com

We did the certificate swap over the weekend since we weren’t 100% sure if it would cause issues with Webmail, Activesync, etc. Luckily no major service disruptions happened once we assigned services to the new certificate. The only noticeable effect was an informational pop up on our Macs running Outlook 2011. The pop-up asked to confirm that Outlook 2011 was going to accept the new configuration information from out Exchange Server. Once assigned our XP PC’s running Outlook 2007 or 2010 could successfully access Outlook Anywhere.

Posted in Exchange 2010, Outlook, Outlook Anywhere | 2 Comments

Moving large VMDK’s from one Windows File Server to another in vSphere 4.X while maintaining share information

Moving large VMDK’s from one Windows File Server to another in vSphere 4.X

At my Job we are nearing the end of our W2k8R2 upgrades. The only W2k3 servers left are our file servers. In planning to upgrade these W2k3 file servers we decided to create the new W2k8R2 file servers in advanced and during scheduled down time migrate the VMDK’s holding the shares to the new VM.  An overview of the plan was as follows:

  1. Create a new W2K8R2 VM, called NewFileServer
  2. On FileServer (W2k3) remove the virtual hard drive holding the share info
  3. Move the VMDK to the datastore folder of NewFileServer and attach it to NewFileServer
  4. Verify data is ok, if so rename FileServer  to OldFileServer and rename NewFileServer to FileServer
  5. Recreate shares and verify access works on FileServer (W2K8R2), if so remove OldFileServer

Below are the actual steps

  1. Ensure a recent backup of the W2k3 source VM has been made
  2. Remove all snapshots from the W2k3 source VM
  3. Export Share information from the Registry of the W2K3 source VM
    1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
      1. This contains names and security for all types of shares (printers, files, etc)
  4. Under Windows uninstall the hard drive containing the share data and power down the W2K3 source VM
  5. In the vSphere client remove the virtual hard drive from the W2K3 source VM
  6. While still in the vSphere client go to the Datastores and move the VMDK to the proper datastore folder where the W2k8R2 target VM is located
  7. In the vSphere client add the new disk to the W2k8R2 target VM
  8. Go to Disk management and bring the disk online
    1. It may show up as a foreign disk that needs to be imported
  9. Verify file data is intact
  10. Rename or dis-join the old VM from the domain and change IP from static to DHCP
    1. The AD account should remove itself if renamed.
    2. If disjoined the AD account will rename but the AD account cannot be reset,  it will need to be deleted and a new one will need to be created
  11. On the new VM rename it’s Window’s computer name to match the old VM, and change IP to static and then restart
  12. Once rebooted Import the exported registry file and restart
  13. Or just restart the Windows Server Service
  14. Verify that the shares work

House Keeping

This doesn’t need to be done but it helps make sure the VM files and Datastore folders match the VM’s AD name

  1. Shutdown and remove both VM’s from the inventory of vCenter (DO NOT DELETE THE VM’s)
  2. Browse to the datastore and create a new folder for the old VM
  3. Move all the files of the old VM to the new folder
  4. Move all the files of the new VM to the old VMs folder, delete the now empty new VM folder
  5. Login to the to a host that has access to the Datastore
    1. Login into the ESXi host via SSH
      1. If SSH is not on then login into ESXi console of the host you’re working with
      2. Turn on SSH access
        1. Set the SSH timeout for 30 or 60 minutes so you don’t have to remember to turn it off
    1. Browse to the data store, eg.
      1. cd "/vmfs/volumes/NX4-SATA-RAID5-01/Intranet/"
        1. The CLI is case sensitive
    1. Find the VMDK in question and rename it by
      1. vmkfstools -E mail2_2.vmdk intranet_2.vmdk
      2. The Flat file will get renamed once the vmdk is renamed
    1. Verify the file was renamed by running ls- l
    1. The various other files can also be renamed in in the CLI as well, e.g.
      1. mv vm-old.vmx vm-new.vmx
      2. This needs to be done for  the following file types
        1. NVRAM
        2. VMSD
        3. VMX
        4. VMXF
      1. Description of those files if you are curious
    1. Stay logged in on the off-chance you need to reenter the SSH, otherwise logout
  6. Once finished browse to the datastore and rename any non VMDK file that still has the old name
  7. Re-Add both VMs to the inventory
  8. For both VMS, In the VM settings remove the entry for the OLD VMDK and add the renamed VMDK (make sure it’s SCSI (0:0) Hard disk 1)
  9. Turn both on VMs, when prompted select “I moved it”
  10. Verify both still function.
  11. Check any auxiliary info (Repoint Backup Agents etc.)
  12. Log out of the SSH session if you already haven’t
Posted in File Shares, VMware, W2K8R2, Windows | Leave a comment
  • Archives

  • October 2018
    M T W T F S S
    « Jan    
    1234567
    891011121314
    15161718192021
    22232425262728
    293031  
  • Page list