Outlook 2016

Issue: Outlook 2016 (which I am testing) cannot connect to Office 365 Exchange.

It is no longer possible to manually enter Exchange Server details. A valid Autodiscovery record is required. Use this site to find out which autodiscovery mechanism you are using.

• https://testconnectivity.microsoft.com/

Verifies that we do have a valid autodiscovery record and that we use the HTTP Redirect method. It also shows that Outlook tries several other autodiscovery methods before the correct (for my organisation) HTTP redirect method.

Solution

What is actually happening is that Outlook 2016 on the PC is hanging when performing the HTTPsAutoDiscoverDomain method. We can force it to use the correct method by the following registry entries.

• http://www.slipstick.com/outlook/exchange-account-set-up-missing-in-outlook-2016/

If Outlook is slow finding the autodiscover records, you may need to tell Outlook to exclude the root domain or other records.

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover\
DWORD: ExcludeHttpsRootDomain
Value: 1

The other records you can exclude, also under the Autodiscover key are as follows. Use a value of 1 to enable, delete the key if you no longer want to exclude these checks.

DWORD: ExcludeScpLookup
DWORD: ExcludeHttpsAutoDiscoverDomain
DWORD: ExcludeHttpRedirect //I DON’T EXCLUDE THIS ONE BECAUSE I USE IT
DWORD: ExcludeSrvRecord

Advertisements

Rename UPN – O365 Powershell

Login to Windows Azure Active Directory Module for Windows PowerShell with Office 365 administrator credentials and run the following command:

Set-MsolUserPrincipalName -UserPrincipalName mary.osgood@contoso.onmicrosoft.com -NewUserPrincipalName mary.smith@contoso.com

Duplicate Users in Office365

 

Both saying synced with AD however only one account exists

I’ve had to manually delete users from O365 during a DirSync deployment. Use PowerShell on the server running DirSync to run these commands:

Import-Module MSOnline

Connect-MsolService  [Enter your Office 365 admin credentials when prompted]

remove-msoluser –userprincipalname UID@UPN.com

If the account is in Deleted Users in Office 365, append the last command with -RemoveFromRecyclebin

Removing Inactive Domain Users from Global Address List – Azure AD SYNC

Generally speaking, we can use “Hide from Exchange Address lists” to achieve it.
You can hide the account from the Global Address List in Office 365 by setting the msExchHideFromAddressLists attribute for the object to “true” in their on-premises Active Directory. The prerequisite is that on-premises AD schema is extended for Exchange. You can open the Properties of this accout, and then locate the Attribute Editor tab to check this attribute.

Please refer to this article to see the attributes that are synced from local AD to Windows Azure Active Directory: http://social.technet.microsoft.com/wiki/contents/articles/19901.dirsync-list-of-attributes-that-are-synced-by-the-azure-active-directory-sync-tool.aspx

You can see the attribute msExchHideFromAddressLists is listed on the table.
After that, please force DirSync to update the change, and then wait a little time

Office 365 Calendar sharing – share to a group of people within organisation

Good discussion about sharing calendars with distribution groups and why it doesnt work!

https://community.spiceworks.com/topic/1747210-office-365-calendar-sharing-share-to-a-group-of-people-within-organisation

 

Add PST to Office365

https://support.office.com/en-us/article/Use-network-upload-to-import-PST-files-to-Office-365-103f940c-0468-4e1a-b527-cc8ad13a5ea6

.local again!

Full credit to Mark Parris for the original write up

Active Directory: .local domain design and Office 365.

Active Directory: .local domain design and Office 365.

Microsoft since the release of Windows 2000 Server have recommended that any Windows Server environment promoted to host an Active Directory forest/domain should be configured with a registered Top Level Domain (TLD), such as .com, .net, .org etc.

Many companies have ignored this advice and taken the approach of, my internet presence is for example markparris.net so I will therefore call my Active Directory forest markparris.local.

This approach to the .local namespace in Active Directory has caused no real issue, with exception of Apple Mac Integration into the environment (see below).

With the onset of the cloud, premises and off premises computing the .localnamespace now causes a potential issue. The .local namespace issue may be resolved with a simple fix or it could involve a fair amount of remediation work.

In order to use Microsoft Office 365 Cloud Services with an on premise Active Directory synchronised via DirSync to the “Microsoft Cloud” the forests namespace or to be more precise the users UPN (User Principal Name) must be an internet registered TLD.   In most companies this can be easily achieved by setting all cloud users UPN’s to their email address (or another registered namespace) and then this is what the user presents to Microsoft, to be authenticated/validated.

In some companies, the .local UPN namespace may already be in use for something else and a UPN remediation project may need to be completed prior to any Microsoft cloud integration. This could again be a simple resolution or a huge global project.

So to summarise, the recommendation is still not to use the .local namespace in any new Active Directory implementation, if you have utilised the .localnamespace and you have a requirement to implement Office 365, then identify and configure a registered UPN for the affected accounts.

To be fair to Microsoft, they did tell you.

DNS name registration with an Internet registrar

We recommend that you register DNS names for the top-most internal and external DNS namespaces with an Internet registrar. This includes the forest root domain of any Active Directory forests unless such names are sub-domains of DNS names that are registered by your organization name (For example, the forest root domain “corp.example.com” is a sub-domain of an internal “example.com.” namespace.) Article ID: 300684 – Last Review: February 16, 2011 – Revision: 25.1.  http://support.microsoft.com/kb/300684

As I put my thoughts down, it has also become apparent to me that anyone with an Active Directory namespace that uses a TLD namespace that is not registered to them will also have this same issue and will also need to configure new UPN’s.

Apple Issues

Mac OS X: About Multicast DNS

http://support.apple.com/kb/TA20999?viewlocale=en_US

You receive an “unexpected error occurred” error message when you try to access resources on a Windows-based network from your Macintosh computer

http://support.microsoft.com/kb/836413