Licenses could not be assigned or removed due to an error -Azure AD group based licenses

Scenario: Group based licensing is enabled in Azure AD. Exchange online is not assigned through the group based licensed. Newly added users to the group fail to get licenses assigned via the group. Reprocessing the group based license throws error:

Licenses could not be assigned or removed due to an error

Solution: A recent service plan backfilled by the O365 Commerce Team into the Office and Microsoft SKUs Microsoft Bookings a has been added as Enabled on all the licenses. This service plan has a dependency on Exchange Online (Plan 1) or Exchange Online (Plan2).

Disabling the Microsoft Bookings service plan in the affected groups should resolve the licensing error.

Create a Shared Mailbox in Exchange 2007

Create shared mailboxes in Exchange 2007  using powershell  as the EMC in Exchange 2007 doesnt allow you to create shared mailboxes like the new exchange 2010.

You can do this with the help of the new-mailbox cmdlet.

Below is an example of creating a shared mailbox called Info and then assigning the info security group full access to the shared mailbox.

New-Mailbox -Name:’info’ -OrganizationalUnit:’contoso.loal/OU/users OU’ -Database:’Mailbox Database’ -UserPrincipalName:’’ -Shared

Exchange 2007 will now create a shared mailbox and also create a disabled active directory account.

Now to assign full access

Add-MailboxPermission Info -User:’info group’ -AccessRights:FullAccess

You can also convert a mailbox to shared one usin the set-mailbox cmdlet.

Set-Mailbox Info -Type:Shared

Once this is done, you are now able to manage the shared mailbox via Exchange Management console if you need to assign permissions for full access or send as permission. The following powershell command is used to assign send-as rights and read/write personal information.

Add-ADPermission info -User:’info Group’ -ExtendedRights:Send-As -AccessRights:ReadProperty, WriteProperty -Properties:’Personal Information’

Active Directory Replication issues since time jump to the year 2000

Active Directory replication fails with Event 2042 reporting “It has been too long since this machine last replicated” and replication status 8614: “The Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.” and

Time of last successful replication:

2000-11-19 14:09:12

I got this error on a site with 3 DC’s and yes that puts you 12 years back, even before this company existed.
Normal solution would be demote and promote the problem DC, but, after looking around technet I bumped into this article : and an updated article, well that explains it all. the main PDC NTP was pointing at USNO.NAVY.MIL and on November 19th, 2012, time servers at USNO.NAVY.MIL incorrectly provided time samples listing CY 2000 as the current year between the hours of 21:07 UTC and 21:59 UTC (16:07-16:59 EST).

-Run W32tm /stripchart /computer:NTPServerAddress to make sure you are getting the correct time from your new source.

-Set the correct time settings to a known good source.

  1. Locate and then click the following registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
  2. In the pane on the right, right-click NtpServer, and then click Modify.
  3. In Edit Value, type Peers in the Value data box, and then click OK.

-Run w32tm /config /update

NOw ofcourse you are having replication issues as AD replication would have happened when the time was set to the year 2000 and when your time is back from the past you are bound to have replication issues due to tombstone settings.
Proceed with making sure “Strict Replication Consistency” is enable in the registry value(HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistency ) has been set to the default for Server 2003 and greater value, which is 0x1 before you do.“Strict Replication Consistency” will ensure that no lingering objects will be replicated out if they really exist after we force the replication to happen.

Note: This forces the replication even if the AD replication has failed with the partner for more than the tombstone lifetime. In most cases, if the server is really having the replication failure and is not caused by this unexpected time jump issue, you would see new replication errors caused by lingering objects as long as “Strict Replication Consistency” is 0x1; then no lingering objects would be really replicated out.

We will now want to follow

On the downstream domain controller where it reported the replication error code 8614 (ERROR_DS_REPL_LIFETIME_EXCEEDED), setup the “Allow Replication With Divergent and Corrupt Partner” registry value.

  1. Click Start, click Run, type regedit, and then click OK.
  2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
  3. In the details pane, create or edit the registry entry as follows:If the registry entry exists in the details pane, modify the entry as follows:
    1. In the details pane, right-click Allow Replication With Divergent and Corrupt Partner, and then clickModify.
    2. In the Value data box, type 1, and then click OK.

    If the registry entry does not exist, create the entry as follows:

    1. Right-click Parameters, click New, and then click DWORD Value.
    2. Type the name Allow Replication With Divergent and Corrupt Partner, and then press ENTER.
    3. Double-click the entry. In the Value data box, type 1, and then click OK.

No restart is needed. Force replication in AD Sites and Services between the destination source and destination servers.

Remember to change the “Allow Replication With Divergent and Corrupt Partner” value back to 0x0 after the issue has been sorted out.
The DC I was working on had already been rebooted and one of the DC’s had kerberos related issues, so if you have noted this yr 2000 do not reboot DC’s.Event ID 4 is logged in system errors:

The kerberos client received a KRB_AP_ERR_MODIFIED error from the server <computer name>$. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (<domain name>), and the client realm. Please contact your system administrator.

To get around this, on the problem DC where you getting this error set the Kerberos Key Distribution Center Service to manual and stop the service.

-From a command prompt on the broken DC enter the following:
netdom resetpwd /s:name_of_working_DC or PDC/ud:domain\user /pd:*
where domain\user is an administrator of the domain in the domain_name\user_name format. You will be prompted to enter your password.

And now reboot this reboot clears the Kerberos ticket cache and so clears the broken credential attempts that it has stored, one can also run klist /purge and Y to all tickets to be deleted.
Support tools and commands useful to rectify this issue

– eventviewer

-repadmin /replsum

-repadmin /showrepl



support tools windows 2003 32 bit:

Windows Server 2003 Resource Kit tools:

Manage Exchange 2010 Calendar Permissions Using Powershell

You can add  Calendar Permissions Using Powershell for users using the following command:

if user2 needs to access user1’s calendar

Add-MailboxFolderPermission -identity “user1:\calendar” –user “user2” -AccessRights Reviewer

the same can be done to give permission to a security group

Add-MailboxFolderPermission -identity “user1:\calendar” –user “DomainName\securitygroup” -AccessRights Reviewer

Below is the list of access rights and explanation

None                                                   FolderVisible
Owner                                                CreateItems, ReadItems, CreateSubfolders, FolderOwner, FolderContact, FolderVisible, EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
PublishingEditor                       CreateItems, ReadItems, CreateSubfolders, FolderVisible, EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
Editor                                                 CreateItems, ReadItems, FolderVisible, EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
PublishingAuthor                    CreateItems, ReadItems, CreateSubfolders, FolderVisible, EditOwnedItems, DeleteOwnedItems
Author                                              CreateItems, ReadItems, FolderVisible, EditOwnedItems, DeleteOwnedItems
NonEditingAuthor                   CreateItems, ReadItems, FolderVisible
Reviewer                                          ReadItems, FolderVisible
Contributor                                   CreateItems, FolderVisible

Recover deleted Active directory user account and restore Mailbox in Server 2008 and Exchange 2010

Scenario:  Restore user account where the account was accidentally/ purposely deleted and the mailbox resides on an Exchange 2010 in a mixed 2003, 2008 environment. The deleted mailbox is now showing in disconnected mailboxes.

The first step is to recover the deleted user account in AD. Hoping that you have left the tombstones on the server to either 60 days or 180 days which is the default for windows 2003 and up.

There are several ways too restore the account, the most painstaking one using system state restore after booting into directory services restore mode which means downtime.

The easiest and simplest way is using adrestore CLI available from Microsoft, if you need GUI is the best.

Download it from the link and install on the DC.

The how to is available from the developers site and

Now that you have restored the user account the next problem is to connect the disconnected mailbox which is rather easy, just open EMC 2010 right-click on a disconnected mailbox, select Connect and choose a matching user in this case.

If the online maintainence hasn’t run then the deleted mailbox will not show in disconnected mailbox, you will need to run this command in PS

Clean-MailboxDatabase databasename

And now you can connect the mailbox to the user you just restored