Microsoft Outlook has got to be one of the most common business applications that just about everyone uses. So when it fails to open, it can feel like the start of a bad day. One error message that I have encountered a few times now is the “Invalid XML” message when trying to launch Outlook. The most common reason for this error is that the XML file that contains the settings for Outlook’s navigation pane has become corrupted. The navigation pane is the one that is on the left side of Outlook and lets you change between your mailbox, folders, calendar, contacts, tasks, etc.
So how do we fix the error? The first thing to try is to simply reset the navigation pane.
- Hit ‘Windows+R‘ on your keyboard to open the ‘Run‘ window.
- Type in the following command: Outlook.exe /resetnavpane
- Hit the ‘OK‘ button.
- Then re-launch Outlook to verify that everything is working.
If the above action did not resolve your Outlook issue, then the next course of action would be to delete the actual XML file and force Outlook to generate a new/fresh file the next time it opens. Here’s how we can do that.
- Hit ‘Windows+R‘ on your keyboard to open the ‘Run‘ window.
- Type in the following command: %AppData%\Microsoft\Outlook
- Hit the ‘OK‘ button.
- It will open ‘File Explorer’ and take you to the directory that the XML file resides in. Look for a file named ‘Outlook.xml‘
- Delete the XML file.
- Then re-launch Outlook to check that it is working now.
That is how to fix the Outlook ‘Invalid XML’ error. I hope one of these methods worked for you so you can get back to your emails.
So another gotcha when using O365 in hybird mode with on-prem sync is that you can’t hide a user’s email address [from address books and distribution lists] by using the Exhange Admin Portal. This is because the setting are made on-prem, and those defined values are simply pushing to your AAD tenant in Microsoft’s Azure cloud.
We used to be able to, from the Exchange Management Console on the on-prem server, just open the user and check a tick box to hide their address from everything. The work around isn’t much harder, it’s just buried deeper.
Open the user in your on-prem AD, and navigate the “Attribute Editor” tab.
Scroll down until you find the following attribute.
Setting it to “TRUE” will make the email addess hidden.
Setting it to “FALSE” or “<not set>” will make the email address visible.
After you have made the desired change to the value of the attribute, you just need to wait for [or force] your on-prem AD to re-sync with your AAD.
If you use O365 in hybird mode, with your tenant sync-ed to your on-prem AD or Exchange server, then you will definitely run into an issue if you try to add an alias email address to a user.
When you attempt to add an alias, or alternate, email in your Exchange Admin Center portal you will see this error message.
To get around this you’ll need to edit the user “local” from your on-prem AD. In AD, right-click and open the users’ properties. Select the tab “Attribute Editor”
You will want to look for and edit the following two attributes.
Add the user’s alias/alternate email address into the above mentioned attributes in the form of: smtp:email@example.com
That’s it. Now you just need to let your AD sync back up to the O365 cloud.
WARNING: If you add it in CAPS (SMTP:firstname.lastname@example.org) then it will get interpreted as the default address and not as an alias/alternate email. Make sure that “smtp” is lowercase.
After changing over from on-prem Exchange to O365, I had one user where the recipients of their emails would receive any attachment that was sent as the “dreaded” winmail.dat file instead of the .pdf or whatever file the user was actually sending. It was intermittent however, in that some users would get the actual file and some (all external) would get the winmail.dat file.
First thing that I did was check that user was sending their mail as HTML, and not Rich-Text. After changing that value, I check back a week or so later and the user was still experiencing the issue, so it was time to dig a little deeper. After some searching online I was able to find that this was not an uncommon issue.
The issue happens because the receiver’s email client can not interpret the email message that was sent from Outlook in the Rich-Text format. When using Outlook to end an email using the Rich-Text format, a plain text copy of the email is also sent along with an attachment named winmail.dat. This ‘winmail.dat’ attachment is what contains all of the formatting, elements, and other data specific to Rich-Text email messages. This method of sending the email message is called “Transport Neutral Encapsulation Format” or “TNEF” for short.
Unfortunately, many non-Microsoft email programs can not properly open message that are received in TNEF. To fix this, we can use PowerShell to force Exchange Online to convert Rich-text messages to HTML before it sends it off. You can use the commands shown below to set the ‘RemoteDomain’ property “TNEFEnabled” to false on the Default policy.
1) Connect to Exchange Online via Powershell.
2) Get your Default RemoteDomain policy:
Get-RemoteDomain | fl *
3) Set the TNEFEnabled property:
Set-RemoteDomain Default -TNEFenabled $false
Re-run step 2 and you should see that “TNEFEnabled” is set to “False”.
Just in case… Here is how to change it back to a NULL value to undo your change in step 3, and let the Outlook client again decide how it wants to send the message.
4) Set the TNEFEnabled property back to NULL:
Set-RemoteDomain Default -TNEFenabled $nul
Out of an entire organization, we had one single machine that had issues installing O365, it would always get stuck at “51%”. I even let tried letting it run for an entire weekend. The weird part was that it was a Win10 machine, and it was all up-to-date in terms of applying Windows Updates. The same ODT script worked perfectly fine for all the other machines that were a mix of Win8.1 & Win10.
So I gave the Office 365 uninstaller a whirl. It ran thru pretty quickly and said everything was removed. It ran so quick, it didn’t even seem like it did anything. I went ahead and tried my ODT script again. and voila – It worked!
So my only take away, is if you’re having issues with the installer “stalling” out, try MS’s uninstaller and try your install again.
Multi-factor authentication is something that you should have enabled in your Azure or Office 365 tenant. It’s going to solve at least 90% of your problems about worrying if someone is going to ‘hack’ into your organization. That said, it can provide a few headaches of it’s own.
When your user is choosing their methods or means to authenticate, one of the options is to use their “Office Phone”. That great… But if you sync your on-prem AD to AzureAD then you’ll quickly realize that that option is grayed out and you can’t set it. You’ll get some message about contacting your administrator.
To set this number, simply edit the properties of your user in your on-prem AD.
- Open “Active Directory Users and Computers” and navigate to your user.
- Right-click on the user and choose ‘properties’.
- Under ‘Telephone’ enter the user’s phone number, country code first, like either of the examples below.
- +1 8085551234
- +1 8085551234 x123
- Click ‘OK’ to save the edits.
After you have finished editing the user, all you have to do is wait for next sync cycle. From then on, your users will be able to authenticate and login by using their work desk phone.
Had an issue today with a user using O365 Outlook. Whenever they tried to open a message in a new window, it open it as a minimized window, showing only dots, then the minimize/full screen/close window icons.
I could use the “windows key + [ARROW]” buttons to move and essentially resize the window. But after closing and re-opening the message, it was the minimized window as before. I tried resizing it and holding “SHIFT” when closing the window, but that didn’t work either. Everything i tried basically wouldn’t persist. Every time i closed the window and reopened it, it would be that same minimized window.
What did end up working for me was to close Outlook, and make a registry edit. This is the registry key I deleted:
After that, opening messages in a new window worked as expected again.