bradcstevens

ADMT Breaks Default File Associations Registry

On my most recent project with a customer, I decided to take on a task of filling in for a fellow engineer who became unavailable on a project he was working on.

Since I was on the bench, I figured why not take on a few hours of ad-hoc work to fill in some time.

With this particular work, I was tasked with resolving a couple of issues, specifically one that intrigued me when using ADMT v3.2.  (Active Directory Migration Tool)

Not too long ago, Microsoft updated ADMT v3.2 claiming support for all currently supported operating systems including Windows 8.

However, I don’t think it is fully supported, nor works as well as Microsoft would probably like to say it does.

With this customer, they had conveyed that they had run into the following issue:

Scenario:

Use ADMT 3.2 to migrate Windows 8* machines to a new domain and forest.

Results:

The migrations finish successful without any problems but when the user logs on to their migrated workstation, all of the default file extension associations are lost. Even after choosing a program to open the file in question, the prompt turns up again if the user chooses to open the file again after closing it. This happens for just about every major default or manually set file extension association such as .jpg, .pdf, .xls, etc.

Why Microsoft? Why?

Turns out that I am not the only one that has been running into this issue however….

In this Microsoft Forum Post several other people have mentioned this issue as far back as 2013!

Until recently, the issue has been closed.

Their support moderator says that “For File Associate issue, is should not related to ADMT.”

By the way, you read that quote correctly. I don’t think this moderator understands the issue, let alone knows how to type out proper English.

Another user does a very good job of describing exactly what is going on, and in more detail to their individual experience:

“The ADMT migration runs perfectly, without issues, but upon completion when a user logs into their PC all their file associations are broken – reg keys under HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerFileExts all seem intact, but until I go in and delete the UserChoices reg key I cannot set these file associations again!

Looking at a PC before and after migration, there doesn’t seem to be any changes (other than the new user is added to the permissions obviously)!

Interestingly, after deleting user choices, I am still not prompted to set “default program” when I double click an affected file type…I have to right click and “Open With” before I see the checkbox to set the default!

Very strange behavior and must be something to do with the security translation of the registry as part of ADMT if you ask me?”

All in all, I was getting nowhere with what I could find, as this forum was the only thing that actually had some relevant pointers for me that applied to what I was experiencing with my customer.

The Fix: 

I was able to fix the issue after trying many different approaches.

One of the strategies was to implement a GPO that set the default file associations on the computer objects post-migration.

The policy I implemented sets the default file associations using the GPO under: “Computer ConfigurationAdministrative TemplatesWindows ComponentsFile ExplorerSet a default Associations Configuration File”

Using the default dism.exe file, as the policy suggests, seems to hold no results even after verifying that the policy was successfully applied to the computer object.

Regardless of this implementation, various file types i.e. .jpg, .bmp, all prompt with an inquiry asking which program you would like to use to open the file, effectively resulting in a non-resolution.

Obviously this is an unacceptable after-effect of the migrations that where promised to be as seamless as possible to the end users.

What did work however, was creating a GPO to run a startup script to run regedit.exe and import a .reg key which sets all the default file extension associations back to the default!

My steps were as follows:

  • Create or obtain .reg keys which contain the settings for file extension associations that will result in the desired effect.
    • Example .reg keys that can be downloaded can be found at:
      • http://www.sevenforums.com/tutorials/19449-default-file-type-associations-restore.html

Placement of Registry Keys (.reg files)

  • Create a GPO in the domain to run regedit.exe with the “/s” parameter specified when pointing to a .reg file set to change the registry keys back to the default settings defined by Microsoft for Windows 8 and Windows 8.1.

Startup Properties of the GPO

  • Apply the GPO to a designated migration OU container
  • Migrate workstations to the target migration OU which has the GPO applied to it.
  • Allow the GPO to apply to the migrated workstation.
  • Once the GPO has been applied, the workstation can be moved to any desired OU, without effecting the results of the applied GPO on the designated migration OU that the file extension GPO was applied to.

Additional Notes:

In my testing, I tried to recreate the registry keys manually (by hand) on the test machine post migration to that of the default key values, regardless of my deleting and creating of new keys, they held no results, even after a reboot of the local machine.

My registry keys included in the GPO I made touch each store on the local machine registry that handles file associations. It deletes the old entries and creates completely new ones that mimic the default associations.

Personally, I am  leaning towards jumbled security permissions post migration, because I couldn’t change the values of the keys manually. I would see an error saying I couldn’t change it. Not specifically a permissions error. I had to delete it all together and create a new key.

The reason why I am not inclined to think the default program definition is a player in this issues, is a result of my experience manually specifying the default program when opening a .jpg for example. I could specify the default program, but it never stuck, meaning every time I opened the .jpg it would prompt again to choose the program I want to use to open it.

Very peculiar behavior. I am inclined to agree with one of the contributors in the forum link I shared with you when he says: “Microsoft needs to understand customer impact so it can prioritize work.”

bradcstevens

Can’t Verify Domain in Office 365

If you have been creating trial tenants over and over again like I have been with Office 365 and their E3 license, it is likely you may run into the same issue I have.

Microsoft does not really give you any hints in regards to troubleshooting your domain verifications.

I am currently going after the MCSA for O365, and the way I have been able to learn the ropes of O365 for the 70-346 and 347, has been purely from signing up for their E3 trial.

No need to spend any money at all, and you can get Sharepoint, Exchange, SfB, etc. Additionally, you get 25 user licenses to play around with.

“What if my trial ends?” you say?

The good news is that you can extend the trial an additional 30 days! (totaling 60 days.) I have a single domain name I used to work with O365 and a lab environment at home that I setup an Exchange hybrid in, manage Sharepoint Online, etc.

Worst case scenario: You use your total of 60 days, and MS asks for money. Just buy another 99 cent throw away domain from godaddy.com or 1and1.com and start another trial. Once MS trashes your original domain which expired, (30 days after your original 30 day, or extended 60 day trial ends) you can use that same domain name again as an O365 tenant and start again.

Rinse. Repeat. Profit.

bradcstevens

The legacyExchangeDN and why it’s a pain in my ***

After a recent Exchange migration project, I can say I officially find the legacyExchangeDN attribute to be a real pain in my ***.

I spent a lot of time troubleshooting and resolving issues in regards to mail delivery due to this little attribute which has caused me to do a small write-up on it’s importance, and what to do when you screw things up like I did.

Background

We are often tasked with migrating from one email system to another, especially in regards to Microsoft Exchange. This could also come in the form of migrating from one domain name to another such as when a business changes it’s name, or when a company acquires another company.

Co-Existence

In an effort to try and make co-existence work, there are several things to consider. For example:

  • Mail Contacts
  • Distribution Groups
  • Mail Users

Once I came up with my messy and convoluted scripting through the Exchange management console, I was able to successfully collect an NDR which contained a string that looked like a bunch of jumbled verbiage. Definitely not human readable.

But, thanks to the wonders of google, I was able to find a way to not only crack the code, but re-apply my lost x500 to my user objects!
*Obscure web ad logo goes here* “I used this one simple trick and techies hate me!”

Just kidding, here is the way I resolved my issue straight from: https://support.microsoft.com/en-us/kb/2807779

The one thing that seems to always come back to bite us is when these mail contacts or mail users are converted to a mailbox, is that all of a sudden users start seeing NDR’s in Outlook barking that a recipient has been deleted and is unavailable.

This is caused by Exchange, which uses an X500 address to route mail internally. Once the attributes have been removed from a user object or contact object in Exchange, and you create a new mailbox for that user or contact, Exchange will automatically create a new X500 address and apply it to the object.

With that said, collecting the legacyExchangeDN attribute from all objects is a must from any disabled or deleted contacts and mailbox users prior to disabling or deleting them.

I found out the hard way, that when you disable a contact in Exchange prior to collecting this attribute, Exchange will wipe all Exchange related attributes including the legacyExchangeDN.

Prior to Exchange 2010 SP1 Rollup 6, the legacyExchangeDN value was something that you could predict and delineate by viewing the syntax of an enabled user. However within newer version of Exchange and within Office 365, Exchange generates a 3 random hex character which it appends to the end of the attribute.

That means you are pretty much screwed in regards to migrating between organizations if you disabled a mail enabled user or contact without collecting this attribute prior.

Or are you?

Well you still could be, but there is a chance you could find it if you make a mistake like I did.

Solving this situation comes down to reporting in Exchange. If you don’t want to wait for users to report on NDR messages, you can search the transport logs for failed deliver messages. This can be accomplished by utilizing a PowerShell query to get the message tracking log.

To create an X500 proxy address for the old LegacyExchangeDN attribute for the user, make the following changes based on the recipient address in an NDR:

IMCEAEX-_O=EXCH_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FHSDHJF23GHYED+29_CN=RECIPIENTS_CN=RON+2EMayers@contoso.com

Convert all _ to /

/O=EXCH/OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FHSDHJF23GHYED+29/CN=RECIPIENTS/CN=RON+2EMayers@domain.com

Followed by….

/O=EXCH/OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FHSDHJF23GHYED+29/CN=RECIPIENTS/CN=RON+2EMayers@domain.com

  • Replace any underscore character (_) with a slash character (/)
  • Replace “+20” with a blank space
  • Replace “+28” with an opening parenthesis character
  • Replace “+29” with a closing parenthesis character
  • Replace “+2E” with a period
  • Delete “IMCEAEX-“
  • Delete “@domain.com”
  • Add “X500:” at the beginning.

X500:/O=EXCH/OU=EXCHANGE ADMINISTRATIVE GROUP (FHSDHJF23GHYED)/CN=RECIPIENTS/CN=RON.Mayers

IMCEAEX non-delivery report when you send email messages to an internal user in Office 365: http://support.microsoft.com/kb/2807779

1. Clear the auto-complete cache file
2. Create an X500 proxy address for the old LegacyExchangeDN attribute for the user

References

Mystery of adding X500’s – Seriously awesome article MSExchangeGuru.com: http://msexchangeguru.com/2012/03/15/x500/

Fixing IMCEAEX NDRs – Missing X500 Addresses: http://www.righthandedexchange.com/2013/02/fixing-imceaex-ndrs-missing-x500.html

All in all this totally saved my life, and definitely caused me to think about how I am going to go about my deleting of contact objects.

bradcstevens

Migrating from Office 365 to Outlook 2010 – Outlook Profiles Cutover

Not many people are migrating OUT of Office 365. In fact it is just the opposite, everyone is migrating INTO Office 365.

I have had the pleasure of working on an interesting project recently. I have been working with a company that has an on-premise Exchange 2010 environment who recently acquired a company that has user mailboxes completely in Office 365. Their end goal: Move everyone out of Office 365 and into an on-premise Exchange 2010 environment.

One of the major drawbacks associated with performing a cut-over migration from both on-premise into the cloud, and from the cloud back to on-premise is the end user outlook profile.

Each Outlook profile at some point will need to be recreated to connect to Office 365 or your on-premise environment.

If this is to be done manually on every migrated user in the company, you could imagine that this could be a very time consuming process, as you would have to:

1. Create a new profile
2. Set it as the default
3. Configure it for the user

I found a way to automate this process using Group Policy to run a script to create a new, blank Outlook profile and set it as the default profile. The end user will be presented with the first time profile setup screen when opening Outlook and should be able to use Autodiscover to automatically find their new Outlook 2010 on-premise profile settings:

I created a PowerShell script  to do the dirty work:

 

This script will create a new profile called “Outlook2010” and set it as the default profile.

Outlook 2010 Registry Settings

Outlook 2013 Registry Setting

A new Group Policy Object will need to be created via Group Policy Preferences to run the PowerShell script.Leaving the GPO in place is safe to do for a few days as it will not overwrite or remove existing profiles. This will allow for people who are to be migrated over time to or are out of office during migrations to see these results.

This is beneficial because if you are like me, you don’t migrate all of your users in a “Big Bang” fashion.

bradcstevens

Exchange 2013 – Pre-stage CNO for DAG creation

The basic steps to creating a DAG of course means having Exchange servers setup prior with their respective databases.

The core components to pre-stage for a DAG are:
1. Designate a Witness Server – In production, best practice suggests in a separate location than that of your DAG(s).
2. Database Availability Group Name
3. Witness Directory
4. Database Availability Group IP address
5. Cluster Name Object
Start by creating a witness server for your DAG.
To pre-stage the witness server you create a folder on the C: drive of the witness server. On my server I call it “ExchangeFWS” so that the witness server has a spot to store its logs, and I can logically identify it later.
Then you will need to add the Exchange Trusted Subsystem to the local administrators group of the witness server.
Follow this by going to your domain controller and creating a computer object (I give mine the same name as the DAG, in my case: DAG01.) This will be the CNO.
While still in Active Directory Users and Computers, enable Advanced Features under the view drop down menu and navigate back to the location of my the DAG01 computer object.
Right click the object and select properties and navigate to to the security tab.
Once here, add the exchange servers computer objects with full permissions.
Exit out of the properties window and right click your DAG computer object and disable it. This is done for security so that you don’t have an unused computer object hanging out in your active directory.
And that’s it!
Now you can get ready to create your DAG.
bradcstevens

Exchange 2013 – Moving and Renaming a Mailbox Database

The default location of a mail database is not really that easy to remember either, so I am going to move my databases from their default location:

That being said, you can either create a new one, or move the existing one.
In this post I am going to move my existing mail database using powershell:
First I need to change the Mailbox Database name to something more suitable.
I do this by logging into the EAC, selecting Servers – Databases – Edit – then change the name of the given database to something like DB01 and then pressing OK.
Then I need to get the exact name of the database:

I used a command like this one to dismount my database:

Now I can move the MailboxDatabase and my LogFolderPath:

Then I need to check the status of my Mailbox Database with something like:

Followed by mounting the database again:

For my own sanity, I finalize this process by running:

bradcstevens

Exchange 2013 – Exporting Certificate Private Keys

As I continue to work with Exchange, I came to a point where I needed to export the private key from a certificate to complete a request with a 3rd party Certificate Authority.
I did some quick research for how to do an export of a private key from a Certificate Enrollment Request Certificate found in my local Exchange Server’s local computer certificate store.
I exported the certificate with the private key and all extended properties.
What I ended up doing was downloading Openssl for Windows, and installing it on my C: drive of my Exchange lab server.
Once installed I opened the Windows CLI and navigated into the directory.
I was able to successfully export the key by running a command similar to this one:

Since you must have a password to obtain the private key, I was prompted to enter the password associated with the certificate file.
After successfully entering the password I was able to find my .pem file which I opened with notepad and was able to copy and paste to the GUI of the 3rd party CA I wanted to use.
bradcstevens

Exchange 2013 – Blocked Port 25? No problem.

Playing in my home lab with Exchange 2013, I came to a point where I wanted to setup e-mail that would be routed to and from the Internet.
My current ISP (Comcast) subscription is a normal home account. That being said, Comcast blocks port 25 (SMTP) from any outbound and inbound connections.
I would just upgrade my account with Comcast to a Business account but I also live with a couple of roommates. I found it hard to justify the jump in price to them if I were to switch the account over to a business account. I’m also just cheap.
As I started to do some research through hours of googling, I couldn’t find any sort of straight forward answer for how to accomplish what I want to do.
If you want to send e-mail out to the internet but your ISP blocks port 25, and you want to do so without having to upgrade to a business account, there are a few things you will need to do:
1. Have about $30 – $40
2. Buy a publicly routable domain name
3. Adjust some port settings on your router
4. Subscribe to an “Outbound E-mail Relay” provider
5. Subscribe to a “Mail Redirection” provider
There are two sites I used to accomplish this:
1and1 – This is where I bought my domain name. New customers get their first domain name for $0.99
DNSExit – This is where I bought the services for Outbound E-mail Relaying and also Mail Redirection. It costs $4.50 a month for 150 outbound mail relays per day. Through this site I was also able to get a trial for 14 days of their mail redirection service. After the 14 days, the mail redirection service is $24.99 /domain /year.

The setup could be summarized as follows:

Buy a Domain

As I stated above, I bought my domain name with 1and1.com. I was able to use their interface to set up the DNS records needed to point to my router. I was also able to set up a subdomain name and point it to my router as well.
So the requirements here were:
  • Set A record for domain name and point to router (My Public IP)
  • Set A record for subdomain name and point to router (My Public IP)
  • Set MX record for mail server. (This will be the FQDN of the mail server that will be forwarding your mails from the internet to your home server. In my case it was “smpt.dnsexit.com”)

Setup Port Forwarding

In my case, I opened port 26 on my routers firewall and set a couple of port forward rules. The rules I set said: For anything coming from the internet on port 26, port forward to my internal Exchange server’s IP addresses on port 26.
I use DD-WRT as my router firmware. The settings above are accomplished by logging into your router, selecting NAT/QOS and selecting the Port Forwarding tab.
An example entry looks like:
Application     Protocol     Source Net     Port from     IP Address               Port to
MAIL              Both          0.0.0.0/0         26                 172.16.100.100        26
If you have already installed your Exchange environment navigate to the Exchange Admin Console and perform the following:
  •      Select Mail Flow
  •      Select the receive connectors tab
  •      Select the Default Frontend
  •      Select Scoping
Within the Network adapter bindings change your IP Addresses port number to one of the supported ports of your chosen provider. In my case I chose port 26.
  •      Save your changes
  •      Select the Send Connectors tab
  •      Create or edit an existing send connector
Set the new send connector to route mail through smart hosts and specify the address the relay provider gives you. In my case it was relay.dnsexit.com. I also left the external DNS blank.
  • Select the basic authentication option and enter in the credentials that your provider gives you.
  • Set the address space to “*” and add your exchange servers.
  • Save your new send connector.
If port 25 is blocked, you will need to do the following as well:
  • Open the Exchange Management Shell
  • You will need to use the Set-SendConnector cmdlet to specify the port of your new send connector.
Example:

Where SENDCONNECTORNAME is the name of the send connector which you named in Step 1 and port 26 could be any open ports from your provider.
If no errors show in the shell then it worked and you are done setting up the outbound relay.
Send a test e-mail from your Exchange server to verify.
Assuming the above is all setup, you should be able to send and receive e-mail from your home Exchange server.
Feel free to drop a comment or share your experience!
bradcstevens

Exchange 2013 – Importing Certificates

In Exchange 2013 installing certificates is fairly straightforward. With a CAS/Mailbox duo setup on three of these configured, I encountered one problem with the certificates that I thought was worth noting.

I wanted to add a certificate to my lab. So I went to one of the free sites (in my case, StartSSL) and got myself a certificate for my lab domain, after submitting my certificate request from my first Exchange server.

Once I had finally received my certificate, I used the Exchange EAC web GUI to import my certificate onto all of my Exchange servers. Exchange seemed happy, notifying me that the import was successful to all servers.

At this point, something isn’t right. I ran into a weird problem. I went to check the certificate I just imported on all of my servers through the GUI and I found that the certificate was only visible on my first Exchange server. This was weird to me because I had not received any errors when the first Exchange server was importing. Naturally I checked the logs, and found no error on any of my servers.

Logically the next step that came to mind was to try to re-import the certificate on the servers that it was not showing on.

What’s interesting is that when I tried to import the certificate directly onto either of the servers, it still wasn’t showing up. I was prompted by Exchange that the certificate had already been installed with its respective thumbprint. This continued after exporting and removing the certificate from each of the servers and starting back from square one.

After getting frustrated, I decided to do a little more digging, I loaded up MMC with the Certificate snap-in to take a closer look at the certificate I had just imported to my Exchange server. I was able to successfully see the certificate I had just imported, but on closer inspection I saw that it didn’t have the private key installed, which in turn makes the certificate useless.

With this new found information, I removed the certificate from all stores on all of my labs Exchange servers. During the removal however from my first Exchange server, I exported a copy of it which included the private key and all extended properties. I then decided to try to import the certificate using the Exchange shell so I could see more of what might be happening on the back-end.

What I found worked, could be summarized as follows:

If you have already installed a certificate like me, make sure you have already removed the certificate from each server you imported it to.

Import the certificate using the Import-ExchangeCertificate powershell command:

This command will import the certificate from a file called mycert.pfx from a file share called share. (Use the UNC path here) The password parameter prompts for a password here, as it is required for a file storing both a certificate and its private key.

Then you would use the command Get-ExchangeCertificate to receive a list of the installed certificate. I used the -server <Server Name> parameter to view each individual server and verify the certificate installed.

Next you would use the Enable-ExchangeCertificate cmdlet to assign the certificate it’s roles with exchange.

This command will enable the certificate with the thumbprint you specify to secure communication over IMAP, POP3, IIS, and SMTP etc.

At this point, you should be practically ready to go with your Exchange certificate. After refreshing the view in the Exchange admin console, you should see the certificate you’ve installed listed on all servers you imported it on.

I will not however that when importing the certificate through PowerShell it does not allow you to give it a friendly name, so you will have to give it one through EAC if you want to easily identify it this way.