Connecting Live.com Accounts to Outlook when they use a 3rd party email address

Posted 30 October 2021, 16:37 | by | Perma-link

I've just had to recreate a number of accounts on a windows PC, and came up against a fairly niche problem:

My family have Live "Personal" accounts that are tied to their primary email addresses, rather than to a hotmail.com or outlook.com account. My webhost provides a nice email service that supports secure IMAP connections for their accounts, so there was no need to set up full mail accounts, but we do use the calendar and contacts options, which are also managed on our phones, and shared between us. However, it's been getting slightly harder to add the live accounts to the desktop version of Outlook, hence this post.

Previously, I'd succeeded by adding the live account first, but that started failing after my host upgraded their systems and started supporting the autodiscover protocols, however I'd been able to create the account as an Exchange Enabled account, and point it to a hotmail.com server, however trying both that and using outlook.live.com seemed to connect successfully, but didn't actually bring down any contacts or calendar information.

I did manage to get it work once I'd found the underlying account that outlook.com had generated for the user. If you log in to outlook.com and hover over the Outlook icon in the top left, you're shown the details of the account - this was an email like outlook_[...]@outlook.com:

Outlook.com underlying account

Using that email address, I was able to get the New Account dialog to recognise that I was adding an outlook.com account, but it complained that there wasn't a user with that email address. Entering the users actual email address and credentials added the account with the Calendars and Contacts to Outlook and then I could add the primary email account from our servers after that.

Filed under: Office365

Setting up Office 365 Directory Synchronization and filtering out users after the effect

Posted 21 May 2012, 17:33 | by | Perma-link

If you're considering moving to Office 365, you've probably been looking into the options for Directory Synchronisation. If your AD is anything like ours, you'll have a number of accounts for services, ex-staff, contractors, etc. that you don't really want synchronised up to Office 365.

By default there's no control over the filtering of accounts within the Directory Sync Configuration tool, and the content on setting this up has been "coming soon" for over 6 months, which is a shame, however, when you run the Office 365 Deployment Readiness Tool you'll see the following line in the reports:

Filters were applied to obtain the above object counts for an Office 365 deployment.

So clearly these filters are configured somewhere - but where?

Hunting around on the web, I've found a very useful post for the initial setup scenario from credera: Filtering Users in the Office 365 Directory Synchronization Tool where they talk about using the UI based on Forefront Identity Manager (FIM 2010) - and suggest you run this before DirSync runs. I failed to realise the implication of one aspect of this: Even if you clear the "Synchroize directories now" so DirSync doesn't force the update, you've started the service and the 3 hour timer - so don't start this just before you go home for the weekend, otherwise you'll end up with all your accounts online like I did.

So how do you implement filtering after you've done initial import? Well, it's not too painful once you've looked around at the systems.

Start by firing up the Synchronization Service Manager through using the miisclient.exe executable found deep in the Sync Service's UIShell folder, and switch to the "Management Agents" pane. Click on the "SourceAD" Management Agent line, and select Properties.
View Management Agent Properties

Then select the "Configure Connector Filter" (apparently you can also do things with the Directory Partitions - your milage may vary), select "user", and create a "New..." rule:
Configure Connector Filter

As I'm only interested in importing users from our "Staff" organizational unit, and groups from our "Company_UserGroups" OU, I set up one filter with the following rules:
Add new filter

"<dn>" "Does not contain" "OU=Staff"
"<dn>" "Does not contain" "OU=Company_UserGroups"

Ok out of the dialogs and return to the "Operations" page. You now need to perform a Full synchronisation to remove the filtered out users:

From the Actions menu, select "Run..."
Actions | Run...

Ensure that "SourceAD" Management Agent is selected in the top dropdown, then select "Full Import Full Sync" from the list of Run profiles, and press "OK".
Full Import Full Sync report

Once that operation shows has a status of "success", select "Run..." again, and this time switch to the "TargetWebService" management agent, and choose the "Full Confirming Import" run profile, and press "OK".
Full Confirming Import report

Once that operation also shows a status of "success", you'll want to run the "Export" profile for the "TargetWebService" management agent.
Export report

As you can see, after each run you should see confirmation of deleted accounts in the reports.

To confirm that they've really gone away, you can then fire up forced run of the standard sync using the powershell command Start-OnlineCoexistenceSync if you run the DirSyncConfigShell powershell script from the root of the DirSync install folder, or by re-running the Directory Sync Configuration Tool.

Just deleting the users from Office 365 using the Remove-MsolUser command obviously didn't work as they were just recreated again with the next diffential sync.

I also found that the event log will contain warnings that your configuration has changed and you need to perform a full sync for the changes to take effect:

The management agent "SourceAD" completed run profile "Delta Import Delta Sync" with a delta import or delta synchronization step type. The rules configuration has changed since the last full synchronization.
 
User Action
To ensure the updated rules are applied to all objects, a run with step type of full synchronization should be completed.

Filed under: Office365