It can happen fairly easily, that one or more user’s Office 365 login is wrong, and AD Sync fails to correct it. Here is a manual override, courtesy of the excellent Joe Busby.
- On a domain controller, verify the AD username and proxy addresses is set correctly.
- Connect to O365 Powershell on any machine with Powershell 5.1, and run this command:
Set-MsolUserPrincipalName -UserPrincipalName "firstname.lastname@example.org" -NewUserPrincipalName "email@example.com"
- On the user’s PC:
- Navigate to Settings > Accounts > Access work or school
- Disconnect from any accounts linked to the new or old username
- Hit the [ + ] Connect button and provide the credentials to sign in to Office 365
- If their password has been changed since their account was synced up with the wrong username, the password may need to be reset.
- Remove any credentials from windows credential manager that match the old username.
- Check Outlook, you may have to create a new profile.
Here is a utility:
which does an excellent job. It will edit, merge, save copies, et cetera. It works also with later versions of Outlook which use .DAT files instead of .NK2 files.
There is also a Microsoft page, with a utility linked, reported to be excellent:
Once you install the Office 2016 templates:
you can set the maximum sizes:
This is a very long list, the most complete list I’ve seen:
Lots of possibilities for cleanup and fixup.
If you see this while trying to share a calendar to another Exchange or Exchange Online user, thus far this has been seen to be caused by (a) duplicate Permissions user entries in the calendar, and (b) user entries in the calendar belonging to deleted, disabled, or otherwise invalid user accounts. Remove the duplicates or invalids, and it goes away!
Sometimes an import to Outlook gets in all of the data, but the data type of the folder is wrong, so Outlook tries to show (e.g.) a Contacts folder as a list of emails. This was easy to fix in olde versions of Outlook, one just pulled up the properties of the folder and changed the type. The Microsoft lords have decided not to give us this easy way anymore, but one of their many major engineers gave us something which will do this among many other things:
This is a very interesting GUI tool which will connect to a recent working Outlook profile, and permit you to do lots of deep things. It’s interesting to google MFCMAPI to see a few of them. You do need the 32-bit version of MFCMAPI if you have 32-bit Outlook, and 64-bit for 64-bit.
In this case, let’s say we have the situation in which we have imported a Contacts folder, but Outlook is showing it as a list of badly formed email forms. To fix it:
- Open the profile in MFCMAPI. (We do not have to close Outlook while this is happening, but we do need to restart it to see results.)
- Double-click on the Display Name of the account you wish to open. There may be just one, or more.
- A window comes up. Open its tree in the left pane using the little arrow to the left of the name near the upper left corner.
- Scroll down and open “Top of Information Store” in the left pane.
- Left-click once on the default Contacts folder for the profile, the one that is working well.
- Scroll in the right pane, down to PR_CONTAINER_CLASS. Doubleclick on it. Under “Ansi” it should say “IPF.Contact”, this verifies you are in the right place. Click Cancel.
- Right-click on PR_CONTAINER_CLASS and choose “Copy property”.
- Open and/or scroll in the left pane to the contacts folder which is not working properly.
- Right-click anywhere in the right pane, the properties list, and choose “Paste property…”. Complete the little wizard.
- The change will be visible immediately in Outlook if it’s open.
- However, at least in the case just seen, the change was not synched to EOL. I had to open the original export PST and recopy, after deleting the file in OWA. One thing not tried yet was to do the above with cached-exchange turned off; in theory this might sync directly through Outlook to EOL. Also, MFCMAPI includes folder copy capability, which may make it an entirely different import method, if it works!
MFCMAPI does lots and lots of things, but not everything extremely well :-) For instance, it may throw errors when deleting a folder stored on EOL; if so, use OWA for this, OWA seems to be much more quickly authoritative.
If you find that inbound emails are not going where they should go, but cannot find any Rules in Outlook or Exchange to match, they may be slightly corrupt and thus invisible. If you run Outlook with
/cleanconvongoingactions , this will eliminate all rules and also a queue which can be involved. A full list of command-line switches for Outlook, is here: