SSTP VPN Bug with Server 2012 R2

Tonight I stumbled across what appears to be a bug/glitch with Server 2012 R2 when attempting to setup an SSTP VPN connection.  I completed the config as per MS best practice with a valid public digital certificate which I obtained from DigiCert however when I went to connect, I received the following error:

Error Code: 0x80072746
Error Description: 0x80072746: An existing connection was forcibly closed by the remote host.

My certificate was bound to the RRAS instance correctly and TCP443 was forwarded through.

 

When I ran a "netsh http show ssl" however it did not show the binding, despite me configuring it in the RRAS interface and the certificate existing in the local computer certificate store with private key.

 

 

I tried changing the certificate in RRAS to another, then changing it back, but still no binding.

 

As a result, I exported the certificate off the machine with Private Key, deleted the certificate, then imported it back with Private Key.  After performing this task, I then rebound it in Routing and Remote Access (RRAS) using the same method.

 

Running the command again, the binding worked.

 

 

 And that's why we get paid the big bucks!

Testing GRE Protocol with PPTP VPN connections

In this post I am going to show you how to test GRE Protocol is open and working when setting up PPTP VPN Servers.  GRE Protocol being blocked on network infrastructure is one of the most common issues faced when setting up a PPTP VPN Server.

The first step is to stop the VPN Server.  This is done by right clicking the VPN server in Routing and Remote Access and clicking "Stop" under All Tasks.  This is done because our testing tool also listens on TCP1723 so we need to ensure this port is no longer in use on the server in question.

 

 

Next download our testing tools called pptpsrv.exe and pptpclnt.exe.  These tools are available in the Windows XP SP2 support tools available from the following URL:

 

http://www.microsoft.com/en-au/download/details.aspx?id=18546

 

Copy the pptpsrv.exe file to C:\Windows\System32 on your PPTP VPN Server then run it from an Administrative Command Prompt.  Ensure Windows Firewall does not block it.  Run the tool on the server and it will begin listening on TCP1723.

 

 

 

Next run the pptpclnt.exe from another remote computer and target it against the PPTP VPN Server like this:

 

pptpclnt.exe 192.168.2.11

 

My local IP address of my PPTP VPN Server is 192.168.2.11.  Then when prompted enter in some sample text to send through the TCP1723 port socket.  I wrote "Hello this is clint".

 

 

Next go back to the PPTP VPN Server and verify the text was received.  We can see that the VPN Server received the text "Hello this is clint" and then went onto the second test of closing down the port socket TCP1723 and beginning a socket for GRE Protocol test.

 

The client automatically goes on to test GRE protocol.  GRE Protocol on my local network is currently blocked by our Cisco Infrastructure (L3 Switch/Router) and as a result we get a Socket Failure error.

 

 

This means I need to go back to the Cisco Infrastructure, resolve this problem then test again.

 

Hope this post has been helpful for troubleshooting PPTP VPN servers.

Shared Mailboxes and Sent Items in Microsoft Exchange

In this post I'm going to focus on an Exchange feature introduced back Exchange 2010 SP2 Update Rollup 4 which has not had heavy exposure out there in the real world however is a feature in demand by many companies.  Ever since Exchange 5.5, companies have been able to create shared mailboxes which multiple users use to access email content.  Users with shared mailbox are able to view incoming email which is handy for many shared mailbox scenarios such an "Accounts mailbox", a "Service Desk mailbox", a "HR mailbox" and so on.  However, when a user with access to the shared mailbox "Sends As" the shared mailbox or "Sends on behalf" of the shared mailbox, the Sent Item goes to the users mailbox, not the shared mailbox.  This means users that share the shared mailbox cannot see the email sent on behalf of the mailbox.

See the problem?

Well this has been addressed in Exchange 2010 SP2 Update Rollup 4 and the latest update rollup in Exchange 2010 SP3.  If you are still on Exchange 2003 or 2007 you will need to upgrade to be able to use this feature.

What Microsoft has done is implement a new feature which "copies" the email "Sent As" or "Sent on behalf" of the shared mailbox TO the shared mailboxes sent items from the users primary mailbox.  This means the sent item will appear in both the shared mailbox and the users mailbox.

This needs to be manually configured on each shared mailbox with the following command:

Set-MailboxSentItemsConfiguration "shared mailbox name" -SendAsItemsCopiedTo SenderAndFrom -SendOnBehalfOfItemsCopiedTo SenderAndFrom

This command configures both SendOnBehalfOf and SendAs, if you only want to configure one of them, simply remove the one you want to not configure.

There is a problem however, this command the Set-MailboxSentItemsConfiguration and Get-MailboxSentItemsConfiguration commands were not included with Exchange 2013 or Office 365 and are still not available in the latest release Exchange 2013 CU8.

However, this feature will be coming out soon in Exchange 2013 CU9 but will have different commands and will no longer use the Set-MailboxSentItemConfiguration and Get-MailboxSentItemConfiguration cmdlets.  The commands instead will use the Set-Mailbox cmdlet with the following syntax:

set-mailbox -MessageCopyForSentAsEnabled $False
set-mailbox -MessageCopyForSendOnBehalfEnabled $False
set-mailbox -MessageCopyForSentAsEnabled $True
set-mailbox -MessageCopyForSendOnBehalfEnabled $True

Also, this feature will be enabled by default on all mailboxes in Exchange 2013 CU9.  Companies will no longer need to worry, shared mailboxes will automatically receive any emails "Sent As" or "Sent on behalf as".

More information on this new feature in Exchange 2013 CU9 can be found below:

http://blogs.technet.com/b/exchange/archive/2015/03/03/want-more-control-over-sent-items-when-using-shared-mailboxes.aspx

Edit: 17-09-2015:

This feature was NOT enabled by Default as originally promised by Microsoft.  As a result you need to enable it on your shared mailboxes with the following commands:

set-mailbox -MessageCopyForSentAsEnabled $True
set-mailbox -MessageCopyForSendOnBehalfEnabled $True

Also in my lab, after installing CU9 I was not able to run the above commands as the following error was received.

A parameter cannot be found that matches parameter name 'MessageCopyForSentAsEnabled'.

 

 After running the CU9 installation, I then needed to manually PrepareAD with the CU9 media.

setup /PrepareAD /IAcceptExchangeServerLicenseTerms

 

After this I was able to enable the option on a shared mailbox.