Thursday, 20 February 2020

Outlook 2016 Office 365 O365 showing recipients name in the to field

Had a weird little problem where one of our clients name was appearing in the To field in all her folders in Outlook 2016/Office 365

Reset the views, didn't fix it - all very strange

Eventually found under "Change View" that a new 4th View had been created called "Show To". Changing it back from this to "company" immediately fixed the problem and the "Show To" view totally disappeared from the list


Client couldnt tell me how it happened, but that seemed to fix it!

Monday, 17 February 2020

Adding L2TP VPN access to SBS 2011 as well as PPTP

Out of the box, Server SBS 2011 isn't enabled for L2TP VPN access, but it does support it. All you need to make are a few changes to Routing and Remote Access:

1. Open Routing and Remote Access under Administrative Tools
2. Go to "Ports", right click it and go to "Properties"
3. In this window, find "WAN Miniport (L2TP)" - it will say 0 in the number of ports column
4. Select it and click "configure" - tick the "Remote Access connections (inbound only)" box and increase the maximum number of ports (to the number of connections you need)
5. Now right click on the server name (local) and select "Properties"
6. Go to the "Security" and tick "Allow custom IPsec policy for L2TP Connection"
7. Int he box below, enter a preshared key. You will need to give users connecting to the network this key
8. Click OK and restart RAS
9. You now need to forward port 1701 from your router to the server (you can leave 1723 in place for PPTP, as both will work)

And thats it - you should now have working remote VPN access to your server using L2TP

Tuesday, 21 January 2020

Client reconnecting to Exchange 2010 after migrating to Office 365


After our first 365 migration we left the mail-server online to export more folders but had an annoying problem where after using Outlook for a while they would start trying to use the old server again as the mail server. It worked, but wasn't quite right - and eventually stopped working altogether.

The reason for this is that Outlook still looks on your local network for an auto-discover virtual directory - so if you need to keep the mail-server on be sure to remove the auto-discovery folder!


  • View your current autodicover information (I tend to take a screen grab)
    • Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, Identity
  • Remove your autodiscover info (be sure to replace SERVER with your server name)
    • Remove-AutodiscoverVirtualDirectory -Identity “SERVER\Autodiscover (SBS Web Applications)”
    • Alternatively, read what the folder is called, as you may need to run
    • Remove-AutodiscoverVirtualDirectory -Identity "SERVER\Autodiscover (Default Web Site)"
And that should fix it!

Migrating from On Premise Exchange to Office 365 - upload PCs from the server

We're doing a lot of migrations at the moment; everyone seems to want to dump their on-premise exchange server and head to the cloud. I've read a lot about 365, but something managed to pass me by and this week (3rd migration) I've finally found out about it.

Importing PSTs to the 365 servers from their side; how I missed this I just don't know.

This new process has shaved a lot of time from the migrations, so here goes the new work routine:

1. End of play for the weekend; change MX records to point to 365 and turn off port 25 and 443 on networks firewall
2. Use Exchange Powershell to export all of the PST files from the server into a folder
3. Use AzCopy to upload the PSTs to Office 365
4. Create a mapping file and upload it to Office 365
5. Run the mapping file and import the PST files into the mailboxes
6. Add the accounts to all PCs and off we go

To do step 3 you need to get your SAS URL which is generated from the Office 365 portal and then enter it into the AzCopy cool (its basically the destination on an Azure cloud server).

Read the full Microsoft Documentation here

Here are a few useful commands that you may need following the above steps:
  • Having trouble exporting emails from the server because of bad items in a mailbox? use the below switches:
    • New-MailboxExportRequest -mailbox jsmith -filepath "\\server\PST\jsmith.pst" -baditemlimit 50000 -acceptlargedataloss
  • Need to view the progress?
    • Get-MailboxExportRequest
  • Want to clear the finished exports from the report?
    • Get-MailboxExportRequest -Status Completed | Remove-MailboxExportRequest
  • Here's an example from the mapping file:
    • Workload,FilePath,Name,Mailbox,IsArchive,TargetRootFolder,ContentCodePage,SPFileContainer,SPManifestContainer,SPSiteUrl
    • Exchange,,jsmith.pst,jsmith@contoso.co.uk,FALSE,/,,,,
  • Still having people connecting to the old server after migration? did you remember to turn auto-discovery off on the server? read me!


WordPress redirecting to Random Websites such as tomorrowwillbehotmaybe

A client recently had a problem with their WordPress site where it kept redirecting to a random URL - investigation showed that it went to tomorrowwillbehotmaybe in this instance.

The site hasn't been updated in a while (they are self client managed), and the issue appeared to be with a plugin called 301 simple redirect.

Disabling the plugin by renaming the plugin folder resolved the issue and the client could get back into the site as needed. Seems as though this particular plugin has a security hole in the older versions which got plugged - fine as long as the sites getting updated!

Monday, 1 July 2019

Exchange 2010 - OWA Outlook web App couldn't connect to Exchange Web Service due to a configuration error. Response code = "null, webexception.status = RecieveFailure" Can't delete emails OWA

Having moved a few Exchange 2010 servers over to TLS 1.1 and 1.2 one of the more recent ones we did kept coming up with the following error when trying to delete emails from OWA

Outlook web App couldn't connect to Exchange Web Service due to a configuration error. Response code = "null, webexception.status = RecieveFailure"

The error message in OWA when trying to delete email is as below:



This is a by-product of using TLS 1.1 and 1.2 - the internal schannels seem to struggle communicating with it if things aren't just quite right.

We managed to fix it by checking all of the following:

- Ensure you're running Exchange Rollup 28 for SP3 (lower versions may work, but we got it sorted after 28)
- We disabled TLS 1.0 and enabled 1.1/1.2 using IISCrypto but upon checking the registry keys, they were all set to ffffffffff instead of 1

Therefore, double check the following if using IIS Crypto

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]“DisabledByDefault”=dword:00000000“Enabled”=dword:00000001
“DisabledByDefault”=dword:00000000
“Enabled”=dword:00000001
“SystemDefaultTlsVersions”=dword:00000001
“SystemDefaultTlsVersions”=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
And then also check that .net 3.5.1 has TLS 1.2 enabled:
The next step is to enable TLS 1.2 for .NET Framework 3.5.1. To do this, make the following registry changes:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
After doing all of the above we rebooted and the issue seemed to be resolved.

Exchange 2010 Rollup 27 - Installation ended prematurely because of an error. Your system has not been modified. To install this program at a later time, please run the installation again.

We've been upgrading exchange servers to Rollup 27 and this old chestnut has reared its head again:

Installation ended prematurely - rolling back changes

The solution? run the installation from an elevated command prompt