Office 365 Exchange Rules Allowance & Execution of Scripts Error

I have recently been migrating my work, personal and a few other domains, including clients to a new Microsoft Office 365 tenants. Nothing new to report here, however due to having many rules in place on some of the mailboxes I have needed to update the rules allowance on several of the mailboxes away from the default 64KB to a higher amount (in my case I chose 265KB as this is the maximum allowed). Now this was always a simple task on a locally hosted Exchange, simply done through PowerShell, and it turns out it can still be done this way on Office 365, but with a few more added steps to connect to the PowerShell system on the Office 365 Outlook server.

Firstly you want to open up PowerShell and input the command

$O365Creds = Get-Credential

This tells PowerShell to ask for a credential via the familiar login popup box.


This credential box DOES NOT check the credentials validity, it simply grabs them and puts the in a variable called $O365Creds.

Now we are going to actually connect to the system so we can start doing something

$O365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $O365Creds -Authentication Basic –AllowRedirection

That commands opens the session, if you have the wrong credentials you will get an error stating

New-PSSession : [] Connecting to remote server failed with the following error message :Access is denied.

If this happens simply re-run the credential request command, then re-run the session creation command

Once successful you will connect to the PowerShell server, with this you will most likely get a warning stating the following:

WARNING: Your connection has been redirected to the following URI:

This is due to the “–AllowRedirection” switch in the session creation command. This switch is there to allow a single URL to redirect to multiple PowerShell servers within a cluster and is needed in an Office 365 system is a cluster and there is no way of knowing which PowerShell servers have empty sessions available on them, consequently the above warning is to be expected and not a concern

Both these are shown below;


Now we want to import the remote session (and consequently import the command information) to our local PowerShell session to do this we run, a progress bar will display in PowerShell as this is happening

Import-PSSession $O365Session


When doing this you may get an error if you are doing this for the first time, or where the Execution Policy settings changed

Import-Module : There were errors in loading the format data file:
Microsoft.PowerShell, , <<File Path>> cannot be loaded because the execution of scripts is disabled on this system.


To get over this error you need to run an elevated command prompt (you DO NOT have to close the original PowerShell window) and run the following command

Set-ExecutionPolicy Unrestricted

PowerShell will give you a warning stating that this may potentially expose your system to security risks, either enter Y (for yes) and hit enter, or simply hit enter (as Y is the default) if you are happy with this


Once this is done re-run the PowerShell import command, it should now succeed

Now we can run the command to increase the amount of space for the rules which is a simple one line command

set-mailbox -identity mailbox@domain.tld -RulesQuota 256kb

This command expand the rules quote of mailbox mailbox@domain.tld to 256KB (this is the maximum available)

This command will not show any confirmation it will simply drop to asking you for the next command to input. Input any other rules upgrades (or any other commands you want to run remotely) and then log off

To do this simply run;

Remove-PSSession $O365Session

This will again show no confirmation and will simply drop you to the next command prompt

Have Fun


Fixing a Corrupt Active Directory Database

Recently I was contacted by a colleague who was having issues with an Active Directory database. Whist there is nothing unusual in this colleague contacting me for help or vice-versa, this issue was beyond the norm.

What he had reported to me was that there was issues with the primary domain controller (PDC) and secondary domain controller (SDC) on this site having out of sync databases, which came to the fore as he was adding new devices (through WDSUtil) to be imaged, they appeared on the SDC but not on the PDC, with this causing issues predominantly with the fact they would image the machine, and get the correct name from the SDC which was also acting as the (Windows Deployment Services) WDS server but it would not bind to the domain, as there was no account for it on the PDC.

Upon further investigation (over the phone at this point) we discovered the the two domain controllers were out of sync and the tombstone had exipred, fixing this problem allowed for a partial sync as outlined below;

PDC==>SDC – Success
SDC==>PDC – Fail

PDC ==>SDC – Success
SDC==>PDC – Success

These tests were run from the “Active Directory Sites and Services” tool on the domain controllers as shown above.

Looking at the error logs it showed AD Domain Services errors of 1988  and an error stating

Active Directory Domain Services Replication encountered the existence of objects in the following partition that have been deleted from the local domain controllers (DCs) Active Directory Domain Services database. Not all direct or transitive replication partners replicated in the deletion before the tombstone lifetime number of days passed. Objects that have been deleted and garbage collected from an Active Directory Domain Services partition but still exist in the writable partitions of other DCs in the same domain, or read-only partitions of global catalog servers in other domains in the forest are known as “lingering objects”

It did also give a whole bunch of sensitive information (hence I will not publish it) stating the object that was causing it. Looking for the cause of the error I came across the repadmin (AD Replication Admin command line tool)- repadmin /removelingeringobjects ServerWithLingeringObjects CleanServerGUID NamespaceContainingLingeringObject which I ran, and I ran the replication tests again and got the same results.

So figuring I had nothing to loose I deleted the object that was referenced in the error, which in my case was a user, so I do this and try the replication again. This time I got an error stating that “An internal error occurred”, great what next. Looking at the error logs again (on the PDC, as by this time I was pretty sure it was the PDC that was causing the issues) I found an error of 467 meaning a corrupt database…. Oh SHIT… ok not that bad really but still.

I decided that I would try to repaid the database directly rather than using ADRM on the server (as I only had remote access). I stopped the Active Directory Domain Services – service in the Services Manager (services.msc) and knowing that the AD database is a JET database and that it is stored in C:\Windows\NTDS (NTDS Stands for NT Directory Services) I copied the file ntds.dit (the AD Database itself) to the desktop twice (two different file names, one to work on one to back up)

So once I had the two files I ran a verify on the database through the command esentutl /g C:\Users\<USER>\Desktop\ntds.dit the results coming back that the database is in fact corrupt so I ran the fix esentutl /p C:\Users\<USER>\Desktop\ntds.dit I then moved the fixed file back to C:\Windows\NTDS, restarted the Active Directory Domain Services – service in the Services Manager (services.msc) ran the replication tests again, and they all passed

Crisis averted, and I am now owed a good bottle of Scotch Whisky

This was all done over a remote session so it is possible