Some Notes on the Machines

This is a very long list, the most complete list I’ve seen:

https://www.howto-outlook.com/howto/commandlineswitches.htm

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:

https://github.com/stephenegriffin/mfcmapi

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:

1. 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.)
2. Double-click on the Display Name of the account you wish to open. There may be just one, or more.
3. 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.
4. Scroll down and open “Top of Information Store” in the left pane.
5. Left-click once on the default Contacts folder for the profile, the one that is working well.
6. 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.
7. Right-click on PR_CONTAINER_CLASS and choose “Copy property”.
8. Open and/or scroll in the left pane to the contacts folder which is not working properly.
9. Right-click anywhere in the right pane, the properties list, and choose “Paste property…”. Complete the little wizard.
10. The change will be visible immediately in Outlook if it’s open.
11. 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 /cleanrules and /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:

https://support.office.com/en-us/article/Command-line-switches-for-Outlook-for-Windows-079164CD-4EF5-4178-B235-441737DEB3A6

“Sync Issue” messages, especially “Conflicts”, can pile up in Exchange mailboxes when Outlook is used. There is a server-side method of handling this:

1. In the Exchange console, under Organization Configuration, under Mailbox,
2. Create a Retention Policy Tag, tag type Sync Issues, age limit 3 days. Set Action to Take as Permanently Delete.
3. Create a Retention Policy using the above Tag. Add any or all involved mailboxes, to it.

One uses help/about to get a Build Number, and then one looks up the build number on this page:

http://social.technet.microsoft.com/wiki/contents/articles/240.exchange-server-and-update-rollup-build-numbers.aspx

If a user sees an error message pertaining, run this in the Exchange command prompt:

set-mailbox username -RulesQuota:256KB

The default is reportedly 64K.

By default, in Exchange and Outlook versions after 2003, everything is always done in Unicode mode, with unlimited maximum mailbox/PST/OST size, not counting higher-level server quotas and the like. However, after migrations, older settings may remain, and mailbox size maximums will often eventually crop up because users which existed before migrations may still be in non-Unicode mode, which incurs a hard max on their mailbox size.

The best solution this writer has found, is in Group Policy:

http://technet.microsoft.com/en-us/library/cc179012%28v=office.12%29.aspx#EnforceUnicode

One does have to install the Outlook ADM template into Group Policy.

Go to the Exchange console, under Organization Configuration, Hub Transport, properties of the item(s) in the Remote Domains list, Message Format tab. Choose “Never Use” under “Exchange rich-text format”.

http://social.technet.microsoft.com/Forums/exchange/en-US/10df55b7-1ea4-4539-96a1-8c2b6540f202/exchange-2010-sends-attachments-as-winmaildat?forum=exchange2010

Here’s where and how to set this: