Category Archives: CSP

Cloud Solution Provider

Permanently delete users from Office 365

When you delete user accounts from Office 365 (en thus Azure Active Directory) these accounts are not permanently deleted, but they are kept in a Deleted Users container for 30 days. This is not only true for cloud users that are deleted in the Microsoft Online Portal, but also for synced users that are deleted in your on-premises Active Directory.

clip_image002

Although you can see the deleted users in the Microsoft Online Portal, there’s no way to permanently delete them here.

The solution is to use the Azure Active Directory Module for PowerShell, using PowerShell you can actually permanently delete these user account.

To retrieve a list of all users in the Deleted Users container open Azure Active Directory PowerShell and execute the following command:

Connect-MSOLService
Get-MsolUser -ReturnDeletedUsers

clip_image004

To permanently remove these user accounts you can use the same command, but pipe the output of the command into the Remove-MsolUser -RemoveFromReclycleBin command. You can add the -Force option to bypass the confirmation of each user deletion (i.e. the ‘Are you sure? Yes[y], No[n]’ message).

clip_image006

Now when you execute the Get-MsolUser -ReturnDeletedUsers command you’ll see the all users are permanently removed.

Please be careful, once permanently removed there’s no way to restore the user accounts!

Office 365 Directory Synchronization without Exchange server Part III

In my previous blog post I explained how to manage your Email attributes in Office 365 by directly editing the Exchange attributes in your on-premises Active Directory. This works fine, but it is not recommended nor is it supported by Microsoft.

In this blogpost I’ll discuss how to add an Exchange server on-premises (or keep the last Exchange server when you’ve moved all Mailboxes to Office 365 for that matter) and manage your Exchange Online environment properly.

Exchange Server on-premises

So, what options do you have? Add an Exchange server on-premises, or keep one of the existing (hybrid) Exchange servers for management purposes. Since this is a green field Active Directory, and there’s no Exchange server on-premises you can use the free Microsoft Hybrid License to for this management server. For additional details on this free Exchange license you can check the Microsoft knowledgebase article KB2939261: https://support.microsoft.com/en-us/kb/2939261.

Continue reading Office 365 Directory Synchronization without Exchange server Part III

Office 365 Directory Synchronization without Exchange server Part II

The question in my previous blog post was “Can we decommission our Exchange servers after moving to Office 365?” and the blunt answer was “No, you cannot decommission your last Exchange server on-premises”.

In this previous blog post I showed you what happens if you synchronize a user to Azure Active Directory from your on-premises Active Directory, and how to create a Mailbox in Exchange Online with a proper primary Email address. At the same time, it was only possible to set only one Email address, and there’s no possibility to add multiple Email addresses, nor is it possible to change any other Exchange related setting.

In this blog post I’ll discuss how to extend Active Directory with Exchange attributes to unleash more functionality and management options in Exchange Online. Please note that the solution in this blog works fine, but it is not recommended and not supported by Microsoft. Continue reading Office 365 Directory Synchronization without Exchange server Part II

Office 365 Directory Synchronization without Exchange server

I get a lot of questions regarding Office 365, Directory Synchronization from an on-premises Active Directory and decommissioning Exchange servers on-premises. A lot of customers want an Active Directory on-premises, they want Mailboxes in Office 365 and they don’t want an Exchange server on-premises anymore.

So the question is basically “Can we decommission our Exchange servers after moving to Office 365?”

It is an easy question with an easy answer, and the answer is “No, you cannot decommission your last Exchange server on-premises”. Let me explain why.

Source of authority

In an earlier blogpost I already discussed the three types of Identities:

  • Cloud Identities.
  • Synced Identities.
  • Federated Identities.

With Directory Synchronization (through Azure AD Connect) in place we’re talking about Synced Identities or Federated Identities. Important to note is that the Source of Authority, which means where the identities are managed, is the on-premises Active Directory. Account are created and managed on-premises and not in the cloud. This is also true for properties of the accounts.

Suppose we have the following situation. There’s an Active Directory environment, no Exchange servers on-premises and there’s an AADConnect server for replication purposes to Azure Active Directory as shown in the following picture.

image

Figure 1. Azure AD Connect is synchronizing user accounts to Office 365.

The internal domain is Exchangelabs.local, the external domain Exchangelabs.nl is only verified in Office 365 and set as the default domain. In the on-premises Active Directory there’s an OU=Accounts where objects are in various OU’s like OU=Groups, OU=Users, OU=Contacts etc.

image

Figure 2. User accounts in Active Directory Users and Computers. Please note the different settings in the E-mail Address column.

The installation of Azure AD Connect automatically detects that there’s no Exchange server installed (the Active Directory Schema is not even prepared, so it’s truly a green-field Active Directory) and thus the Exchange Hybrid option is not available in the setup application:

image

Figure 3. Azure AD Connect is configured with Password hash synchronization

The only option that’s selected is the Password hash synchronization. The Organizational Unit OU=Accounts as mentioned before is the only OU that’s selected for object replication, so after finishing the setup application and the initial synchronization the user account will appear in the Microsoft Online Portal.

When the Office 365 (E3) licenses are assigned to the replicated user accounts, one strange thing is visible. The user account is exactly as expected, i.e. bwesselius@exchangelabs.nl, but the primary SMTP address does not reflect this, and is actually based on the tenant name, i.e. bwesselius@exchangelabsnl.onmicrosoft.com as shown in the following screenshot.

image

Figure 4. User’s email address is set incorrectly. The tenant email address is set as primary SMTP address.

When you want to change the email address from the tenant email address to the regular email address you’ll see the following warning:

image

Figure 5. It is not possible to change the user’s primary SMTP address

The Set as Primary button is greyed out, so it’s not possible to change the email address.

When you try this in the Exchange Admin Center (in Exchange Online) it doesn’t work either and you get the following error message:

The operation on mailbox “Bram Wesselius” failed because it’s out of the current user’s write scope. The action ‘Set-Mailbox’, ‘EmailAddresses’, can’t be performed on the object ‘Bram Wesselius’ because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

image

Figure 6. An error message about ‘write scope’ is shown when the user’s Email address is changed.

Now it gets interesting. Have a closer look at Figure 2. You will see that user BWesselius does not have an email address set in Active Directory, but user Ahaverkamp does have an email address. This is not an Exchange email address (since Exchange is not installed on-premises, Active Directory doesn’t have the Exchange schema changes applied, it really is a green-field Active Directory) but the email address is set in Active Directory Users and Computers.

image

Figure 7. The user’s Email address is set in Active Directory Users and Computers.

When the Email address is set using Active Directory Users and Computers it is synchronized correctly to Office 365 and used in Exchange Online as the user’s primary Email address.

So, now we know how to set the primary Email address when the user is provisioned in the on-premises Active Directory. Despite the fact the user now has the correct primary Email address, it is still not possible to change the user’s Email address in the Office 365 portal or Exchange (online) Admin Center.

This behavior is caused by the fact that the account in this scenario is a Synced Account. The source of authority is the on-premises Active Directory, and this is where all changes need to be made. Once changed the new settings are synchronized to Office 365.

So, to change the primary Email address for user BWesselius it’s a matter of adding the Email address to the mail property in Active Directory users and computers and wait for synchronization to happen (or force directory synchronization). If you want to change an Email address, for example for user AHaverkamp you can just change the mail property of the user in Active Directory Users and Computers.

image

So, now we know how to create a user in the on-premises Active Directory and have the Exchange Online primary Email address set correctly. In my next blog I’ll talk more about an on-premises Exchange server.

Implementing Directory Synchronization

Updated: November 11, 2015,

In an earlier blog I explained the differences between Cloud Identities, Linked Identities and Federated Identities. The source of authority (i.e. where the accounts are managed) for Cloud Identities is Microsoft Online and for Linked and Federated Identities the source of authority is your on-premises Active Directory. To get these accounts in Azure Active Directory (Office 365) you have to setup a directory synchronization between Active Directory and Azure Active Directory.

As explained earlier I prefer to use a dedicated DirSync server instead of installing DirSync on your Domain Controller (which is possible and supported). When using a dedicated DirSync server, you can keep your Domain Controllers identical and work on your Domain Controllers while not affecting your DirSync server. We now will build a configuration like this:

Implemented DirSYnc server

There are two options when setting up Directory Synchronization between your on-premises Active Directory and Windows Azure Active Directory:

  • DirSync as a tool that can be downloaded from the Microsoft Online Portal. This is the ‘original’ DirSync tool which can be installed on a Domain Controller or on a dedicated DirSync server. This tool will be decommissioned somewhere in the (near) future.
  • Microsoft Azure Active Directory (WAAD) Sync Services, the new DirSync tool that can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=44225. This tool has the option to synchronize a multi-forest topology with one tenant in Office 365.

Note. On June 24, 2015 Microsoft has released the Azure AD Connect & Connect Health. Azure AD Connect is the latest version of the Directory Synchronization. This blog is based on the previous Azure AD Sync, but I strongly recommend you look into the Azure AD Connect tool (there are a lot of similarities) which you can download from the Download center.

Continue reading Implementing Directory Synchronization