To begin with, letâ€
s assume a couple things.
Now that weâ€
ve established a baseline, there are a couple of options to perform the task of provisioning an AD user, creating a mailbox, and assigning an Office 365 license.
In this post, I will cover the second option simply because it includes fewer steps and attempts to avoid confusion around where the mailbox should be created.
[su_note note_color=”#ee899a”]Do not create an AD user and then go to the Office 365 portal to create a new user and associated mailbox. This method will not properly create a synchronized O365 user and mailbox.[/su_note]
From the Exchange server, first create the AD user with remote mailbox using one command via Exchange Management Shell (EMS or Exchange PowerShell)…
New-RemoteMailbox -UserPrincipalName "[email protected]" -Alias "UserTest" -Name "UserTest" -FirstName "User" -LastName "Test" -DisplayName "User Test" -OnPremisesOrganizationalUnit "Office 365 Users" -Password (ConvertTo-SecureString "EnterPasswordHere" -AsPlainText -Force) -ResetPasswordOnNextLogon $true
In the command above, I created the AD user in an OU named “Office 365 Usersâ€, set the password to “EnterPasswordHereâ€, and will require the user to change their password at next logon. However, I did not assign an SMTP address or remote routing address assuming that the email address policies are configured to be applied as new mailboxes are created.
Once the AD user and mailbox are created, the AD object must to be synchronized to O365 in order to add the user with associated mailbox in the tenant. With the new version of AAD Connect, the scheduled sync time occurs every 30 minutes. In my case, Iâ€
m not that patient and will manually force a sync to O365.
From the server with AAD Connect installed, via an elevated PowerShell console, run the following command to perform the sync to O365…
Start-ADSyncSyncCycle -PolicyType Delta
This task will synchronize all changes made to AD since the user and mailbox were created.
In the final step, I assign an O365 license to the newly created and synchronized user. The following commands can be run from any machine that has both Microsoft Online Services Sign-in Assistant for IT Professionals RTW and Windows Azure Active Directory Module for Windows PowerShell installed. In my case, they are installed on each server, as well as my admin workstation.
Connect to O365 via PowerShell from an elevated PowerShell console; or using Azure AD Module for PowerShell console.
Confirm the new user does not have an O365 license assigned.
#Connect to Office365 Import-Module MSOnline Connect-MsolService $O365Cred = Get-Credential $O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection Import-PSSession $O365Session Get-MsolUser -UnlicensedUsersOnly
This command returns unlicensed O365 users in which the “isLicensed†parameter is “Falseâ€.
The next command returns the “AccountSkuId“, or subscription license(s), of my tenant that I will use to assign to the new user.
Get-MsolAccountSku
The AccountSkuId will look something similar to “tenantname:ENTERPRISEPACK“; where “ENTERPRISEPACK†represents my Office 365 Enterprise E3 subscription. Other subscriptions will have different representations.
Before I can assign any licenses to my new user, the user must be assigned a location (or country code). Since Iâ€
m am located in the United States, I use “US†as the two letter country code for the user, using this command…
Set-MsolUser -UserPrincipalName [email protected] -UsageLocation US
Now that Iâ€
ve set a location for the new user, I can assign a license from my associated O365 subscription, using this command…
Set-MsolUserLicense -UserPrincipalName [email protected] -AddLicenses tenantname:ENTERPRISEPACK
Finally, the user can access their assigned mailbox in Exchange Online.
]]>The official solution is to Activate the RDS/TS CAL License server and point the Server to License server with User/Device License and will be resolve the problem, but if you want to reset the timer and again avail the 120 days grace time here is the solution:
Delete the REG_BINARY in:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod
To delete the key you must take ownership and give admin users full control.
After a restart of the server RDS will reset the grace period to 120 days.
]]>
This was a simple setup on one server with the: connection broker, Session Host and Licensing server with 2012 R2 CALâ€
s installed.
Even though the licensing seems to be configured correctly, in server manager:

and PowerShell:

Licensing diagnostics:

everywhere you look, everything seems to be OK. But the license manager shows something odd:

No licenses are being used? This server was used since late 2012. Some interesting things could also be found in the event logs, the following events appear:
EventID: 1130
Source: TerminalServices-RemoteConnectionManager
The Remote Desktop Session Host server does not have a Remote Desktop license server specified. To specify a license server for the Remote Desktop Session Host server, use the Remote Desktop Session Host Configuration tool.

and:
EventID: 1128
Source: TerminalServices-RemoteConnectionManager
The RD Licensing grace period has expired and the service has not registered with a license server with installed licenses. A RD Licensing server is required for continuous operation. A Remote Desktop Session Host server can operate without a license server for 120 days after initial start up.

The solution was to delete the REG_BINARY in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod
Only leaving the default.

Note: you must take ownership and give admin users full control to be able to delete this key.
After a reboot the server should be working again, licenses are now being used:

Although everything seemed to be OK and configured correctly with valid licenses, it seems that the setup was still in a 180 day grace period, even though it was correctly configured.
]]>Sometimes admin forget to remove the license for the shared box after conversion and there is no GUI alternative to see if the shared mailbox is licensed. Shared mailbox in Office365 do not require a license.
To find out what shared mailboxes are “accidentally” licensed:
#Connect to Office365
Import-Module MSOnline
$O365Cred = Get-Credential
$O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
Import-PSSession $O365Session
#To view summary information about your current licensing plans and the available licenses for each plan
Get-MsolAccountSku
#Find out shared mailboxes that are licensed
Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails SharedMailbox | Get-MsolUser | Where-Object { $_.isLicensed -eq "TRUE" }
#Find out shared mailboxes that are licensed and remove them
#You need to supply your licensing plan name to remove licenses
Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails SharedMailbox | Get-MsolUser | Where-Object { $_.isLicensed -eq "TRUE" } | foreach {Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -RemoveLicenses "yourlicenseplan:ENTERPRISEPACK"}
]]>