Calendar, SSL, Mailboxes, and more!
Office 365 Calendar Invites
and Meeting Requests……….………3
Alleviate Local SSL Cert Pop Ups………..7
Purging and Removing Deleted Users and Mailboxes
From Office 365 ……….…...11
In this ebook, we will cover Office 365 Calendar Invites and Meeting
Requests Coming Across as Plain-text Email to Non-Mailbox Users within the GAL.
A default setting within Office 365 that can lead to some frustration is that External Contacts and Mail-Enabled Users (not to be confused with Mailbox-enabled) will often will not receive calendar/meeting invites properly in that they arrive in the recipients’ mailboxes as simple plain-text emails that they cannot accept or decline and thus not get placed into their calendars.
Basically, Office 365 uses MAPI Rich Text formatting as the default for these users/contacts, thus transforming HTML messages such as calendar invites into plain-text.
What you need to do is turn off this setting for all Mail
Enabled users and External Contacts that are listed in your GAL.
To do this, for all Mail-Enabled users, execute the following: • GetMailUser Resultsize Unlimited | SetMailUser
• To do this, for one particular mail-enabled user, perform the following command:
Set-MailUser “Alias of User” –UseMapiRichTextFormat Never
• For example, for user information, perform the following: Set-MailUser “information” –UseMapiRichTextFormat Never
• IF you need to back out of this or “undo” for any reason, instead of stating “Never” at the end of the cmdlet, input “UseDefaultSettings” instead.
What you need to do is turn off this setting for all Mail-Enabled users and External Contacts that are listed in your GAL.”
makes this easy.
To do this, for all Mail-Enabled users, execute the following:
•GetMailUser Resultsize Unlimited | SetMailUser -UseMapiRichTextFormat Never
To do this, for one particular mail-enabled user, perform the following command:
•Set-MailUser “Alias of User” –UseMapiRichTextFormat Never
For example, for user information, perform the following:
•Set-MailUser “information” –UseMapiRichTextFormat Never IF you need to back out of this or “undo” for any reason, instead of stating “Never” at the end of the cmdlet, input “UseDefaultSettings” instead.
For External Contacts, the Nomenclature is similar, instead you replace “MailUser” with “MailContact” within the cmdlet.
•GetMailContact Resultsize Unlimited | SetMailContact -UseMapiRichTextFormat Never
To do this, for one particular mail-enabled user, perform the following command:
•Set-MailContact “Alias of User” –UseMapiRichTextFormat Never
For example, for user Dottie Pepper, you need to perform the following:
•Set-MailContact “Dottie Pepper” –UseMapiRichTextFormat Never
NOTE: To get a list of all of either the MailUsers or External Contacts within your Office 365 GAL, input the following cmdlets:
This tip focuses once again on Exchange Hybrid/Coexistence setups and/or migrations to Office 365. In particular, this tech tip discusses how to alleviate the “annoying” SSL certificate pop-up that your Outlook users will start to receive when the Exchange 2010 or 2013 Hybrid server comes online. An example of this pop-up is below:
This occurs because the SSL and/or UCC certificate that you have purchased and installed onto the Exchange 2010/2013 Hybrid server does NOT contain the local/internal URL of the CAS instance of this server, which is often “cas.mycompany.local”, or some kind of local domain that is not publicly searchable/obtainable on the internet. As a result, the local Autodiscover service is configured to initially use “cas.mycompany.local” as its FQDN, which is why Outlook keeps popping-up this message to your end-users.
In the past, some CAS (Certificate Authorities) would allow you to purchase UCC certificates that could secure the local CAS domain instance as well, but because of the new referendum that no longer allow for internal domains to be trusted in a certificate purchased from a CA after November 1, 2015, CAS have already been implementing policies to eliminate this, which means even today in most cases you cannot purchase a certificate to trust an internal domain, which is leading to more and more problems with this internal pop-up message from Outlook as depicted above.
Here are some links which talk about the new CA referendum:
Thankfully there is a way to adjust/fix this internally on your Exchange 2010/2013 Hybrid server so that this is no longer an issue. Essentially, you are going to adjust the internal FQDN to reflect the external, publicly facing FQDN for which you do indeed have an SSL/UCC certificate.
To fix this problem, you need to use the Exchange
Management Shell (EMS) on the Exchange 2010/2013
server. For this example, we will assume that internal FQDN is: cas.mycompany.local, and that the public FQDN
The commands are:
• Set-ClientAccessServer –Identity cas –
• Set-WebServicesVirtualDirectory –Identity “EWS (Default Web Site)” –
• Set-OABVirtualDirectory –Identity “oab (Default Web Site)” –
• If you are utilizing the Unified Messaging Service (UMS), you will also need to input the following:
• Set-UMVirtualDirectory –Identity “unifiedmessaging (Default Web Site)” –
Purging and Removing Deleted Users From
Mailboxes from O365
In this chapter, we will review how to purge/remove deleted users/mailboxes from Office 365 without having to wait for Microsoft’s default 30-day window to ultimately, completely eradicate the account.
This is especially useful if there is a mistake or typo found with a particular user (for example their Display Name) yet they need to use the same UPN for the new and adjusted account. When you delete the user in question, they will be moved to the “Deleted Users” section within the Office 365 portal. It is at this point you are at the mercy of waiting that 30 days (1 whole month), for that thing to finally be gotten rid of.
The problem is, if you don’t purge this account, and you attempt to create the new user with the adjusted settings and the same UPN or primary SMTP address, you will get an error citing that there is already an object with this same information, thus the operation cannot be completed.
This is one of those cases, where waiting for the 30-day window for Microsoft to purge your deleted users and mailboxes simply is not sufficient.
this process soon, but in the meantime the cmdlet’s that you need to fix this are below:
Purge Deleted Users and Mailboxes from Office 365 Single-User Deletion:
In order to permanently purge a single-user from the “Deleted users” section, execute the following:
Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser – RemoveFromRecycleBin –Force
This will work with BOTH DirSync’d and non-dirsynched (Users created directly in the Office 365 tenant).
Bulk User Deletion:
If you have multiple users that need to be purged, you can then execute the command below:
Get-MsolUser -MaxResults 30 -ReturnDeletedUsers | Remove-MsolUser –RemoveFromRecycleBin –Force
NOTE: The –MaxResults parameter is variable, and you can choose a different number other than 30. This particular command will purge the first 30 deleted users that the command encounters. You can adjust this lower or higher. Keep in mind that the higher that you make the number, the longer it will take to run as it is trying to purge/accumulate a larger number of accounts to purge.
Purge External Contacts:
A similar command can be run to purge deleted contacts as well, in case you need to quickly recreate them
Get-MSOLcontact –SearchString “gary” | FL DisplayName, EmailAddress, ObjectID Remove-MSOLContact –ObjectID “ObjectID”
Where “gary” is part of the Display Name for the contact in question.
In this chapter, we will go over using Windows XP with Office 365, especially the new version of Office 365 (Wave 15). For those of you who are moving to Office 365 or are in the process of migrating to Office 365 and still have some legacy workstations on Windows XP, this information will be important to you.
Windows XP End-of-Life
If your organization does still have Windows XP workstations, it is time to either upgrade or retire
them. Microsoft will no longer support Windows XP as of April 2014. Below is an official link from Microsoft that discusses
With regard to Office 365, Windows XP support will end on January 1, 2014. Here is a link that discusses this as
This means, that you have less than eight months to retire and/or
upgrade these systems before support is no longer available for them.
Windows XP requirements for Office 365 integration:
If you can’t get rid of Windows XP just yet, and have no choice but to get these workstations working with Office 365, there are some things that you need know in order to get these workstations to properly connect with the service and working properly. The two items below are essential:
1. Make sure that the version of Microsoft Outlook on the XP machines are as shown below or higher:
Outlook 2007: 12.0.6665.1000 or higher (this encompasses SP3 plus other Microsoft Office/Outlook updates)
Outlook 2010: 14.0.6126.5000 or higher
2. Have we applied the November 2012 Public Update (or later) to all of their Outlook clients?
If these 2 requirements are not met, your Windows XP machines will experience problems with connecting to and working with Office 365 Wave 15.
Something else that is critical, is to make sure that your Windows XP machines have the latest version of Microsoft Update installed (the MSI Installer), if your XP machines are still using the old Windows Update ActiveX control, it will prevent those machines from finding the additional updates needed for Windows and Office/Outlook. Thus, your machines will seemingly be up-to-date with their patches and updates, but in fact they will not and connection problems to Office 365 will still persist.
If you are currently experiencing these issues on your XP workstations, once Microsoft Update gets installed/updated, your machines will find the updates needed to get Outlook, and perhaps Windows XP itself, up to the proper version and thus alleviating any connectivity problems with Office 365.
If you’re interested in improving your Office 365, register for a free trial and see how
Command 365 can help you take control of your business!