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


Using Internet Information Services (IIS) to Redirect HTTP to HTTPS on a Web Application Proxy (WAP)Server

For those of you who do not know, Microsoft’s Web Application Proxy (WAP) is a reverse HTTPS proxy used for redirecting  HTTPS requests from multiple incoming domains (or subdomains) to internal servers. it does however not handle HTTP at any point, which is a failure in itself, I mean it would not be hard to add a part of the system where if enabled it redirects HTTP to HTTPS itself, rather than having to use a workaround, come on Microsoft stay on the ball here, but I digress.

As I stated the main issue here is it does not within the WAP itself redirect a HTTP request to the equivalent HTTPS address. I have played with multiple possible solutions for this including a Linux server running Apache 2 using PHP to read the requested URL and redirect it to the HTTPS equivalent. None of these however have the simple elegance of this solution which includes the HTTP to HTTPS redirect on the same box as the WAP system itself.

First of all you need to log into the WAP server and install the Internet Information Services role. Once done open the management console and you should get a window similar to below.


Now navigate to the required server by clicking on it, and on the right hand side click “Get New Web Platform Components”.


This will open a new web browser window as shown below, when it does simply select “Free Download”.if you have issues with not being able to download the file due to a security warning, you should see the earlier blog here to see how to enable the downloads. Download and install the software via your chosen method.


Once it is installed a new page will appear, this is the main splash page of the Web Platform Installer


Using the search box (which at the time of writing, using Web Platform Installer 5.0, is in the top right hand corner) search for the word “Rewrite”. This will then display a “URL Rewrite” result with the version number appended to the end (which at time of writing this article is 2.0) and click the “Add” button to the right of the highlighted “URL Rewrite” line,


This will change the text on the button to “Remove” and activate the “Install” button the the lower right of the screen, click the install button.


Clicking this install button will bring up a licensing page, click the “I Accept” button (assuming of course you do accept the T’s & C’s)


You will then get an install progress page


Which will change to a completed page after it is done, so click the “Finish” button in the lower right hand corner


This will drop you back to the same original splash screen of the Web Platform Installer, click “Exit


You will now need to close and re-open the IIS Manager and reselect the server you were working on. You should now see two new options, the first being “Web Platform Installer” which we do not need to concern ourselves with any further, the second is “URL Rewrite”,


Double click on “URL Rewrite” and open up the URL Rewrite management console, on the right hand side of this console in the “Actions” pane, click “Add Rule”.


This opens up a box of possible rewrite rules, what we want to create is an “Inbound Rule” as our requests are coming into the server from an external source. Select “Blank Rule” and click the “OK” button


In the new page that opens, in the “Name” field type the name that you want to give the rule, I use and suggest HTTP to HTTPS Redirect, as this tells you exactly what it does at a glance


In the next section, “Match URL” set “Requested URL” to “Matches the Pattern” (default), “Using” to “Regular Expressions” (default) and most importantly “Pattern” to “(.*)” (without the quotes). I suggest you take this opportunity to test the pattern matching.

15-NewRule-Regex Match

In the “Conditions” section, ensure that the “Logical grouping” is set to “Match All” (default) and click the “Add” button.


In the new box that appears enter the following, in the “Condition input” field type “{HTTPS}” (again without the quotes, and yes those are curly braces, not brackets). Change the “Check if input string” dropdown to “Matches the Pattern” and in the “Pattern” box below type “^OFF$” (again, no quotes), and “Ignore case” should be checked. With this one I do not suggest testing the pattern, as even though this system works fine for me, this test ALWAYS fails. Click the “OK” button (mine is not highlighted here as I had already clicked it away and had to re-open the box)


This will take you back to the new rule screen, check the conditions match as shown and then we can move on.


This is the part where we now tell it what we want to do when it matches the previous conditions, in the Action pane change the “Action type” to “Redirect”, Set the “Redirect URL” to “https://{HTTP_HOST}/{R:1}” (again, they are curly braces and of course no quotes), you can select whether “Append query string” is checked or not, but I highly recommend leaving it checked, as if someone has emailed out a URL with a query on it, but not put in the protocol headers (http:// and https:// being the ones we are concerned about) we want the query string to be appended to the end of the redirected URL so they end up where they intended to be. Finally make the “Redirect type” dropdown read “Permanent (301)” (default).


Restart the server service for good measure and there you have it you now have HTTP being redirected to HTTPS which in theory at least is on the same server. Ensure that you have ports 80 (HTTP) and 443 (HTTPS) redirected from your router to the server and the firewalls (and any other intermediaries) on both the router and server set to allow the traffic as required

Enjoy and as always have fun