Powershell

Migrating from SBS 2003 to Windows Server 2012 r2 Essentials in Azure

September 3, 2014 by Paulie 16 Comments

I’ve been considering the idea of migrating customer systems from on-premise Windows Server 2003 SBS to Windows Server 2012 r2 Essentials hosted on Azure for a while now. For one reason or another I’ve stuck to on-premises deployments, mainly due to lack of decent internet connectivity at client sites.

I’ve just completed the first full migration to a fully Azure based infrastructure and it is working well. It was a good fit for this customer because:

The old SBS 2003 server was due for replacement anyway.
Despite only having six users they have a huge amount of email which was shifted to Office 365.
They have closed their office premises and will be working from home based offices from now on.
They have a small line of business application which needs a central server to run on.
SSL VPN functionality of Essentials makes connectivity straightforward and cheap.

The main benefits of running Windows Server Essentials Experience in the cloud as I see it

No hardware to purchase or maintain. The customer had a competitive quote from another IT service provider quoting for physical hardware, which was much more expensive. Cheaper for the customer/more competitive for the partner.
Takes a very short time to get up an running, even in a migration scenario. I was able to start the work without waiting for a box to turn up.
The server resources can be easily modified to suit customer requirements.
The Azure edition of Windows Server Essentials Experience does not have any of the locks or limits of the on-premises edition as it is actually Windows Server 2012 r2 Datacenter edition.
The SSL VPN functionality of Essentials Edition enables remote workers to connect and join to the domain without having to be on the same premises as with previous versions.
The installation of Windows Server Essentials Experience from the Azure gallery is pre-customized to suit a cloud based deployment.

The good news is that if you have completed an on-premise migration to Windows Server Essentials, then the process of migrating to Azure is really not all that different.

Because the process is so similar and because there is so much documentation that already covers the migration procedure already this post is really only documenting the process that I went though and my thoughts on it where that process would differ from a regular on-premise migration.

Broadly speaking, I followed the procedure laid out on Technet here:

http://technet.microsoft.com/en-us/library/dn408633.aspx

Create your Windows Server Essentials Virtual Machine, storage and network

Follow the instructions on this technet article to build your virtual resources within Azure.

http://msdn.microsoft.com/en-us/library/azure/dn520828.aspx#BKMK_CreateVM

For this deployment I have started with a “Small” virtual machine just to see how it runs, I may well increase it in the future.

I was really surprised at how good the performance of a Small Azure Virtual Machinee is, honestly I expected it to be diabolical, but actually it is perfectly adequate for a lot of tasks. There were a couple of parts of the setup procedure which could have used more resources though, so I did at one stage increase the virtual machine size temporarily.

In addition to the base disk I also added a 10Gb drive for storage of active directory and a 180Gb drive for data storage.

Linking the Azure virtual network linked to your on-premise LAN

This step is not strictly necessary as there are a number of different approaches you could take to move data from the on-premise network into Azure. But I chose to link the local network with the Azure virtual network using the Azure site-site VPN capability. This makes joining the new essentials server on to the existing domain easy and makes transferring data more simple.

In this case the customer had a Draytek router and I have written a separate post on how to create a site to site link between a Draytek and Microsoft Azure. There are lots of guides on the net that explain how to achieve the same thing with different router vendors.

In this scenario the link back to the local network will be removed when the migration is complete, but clearly this approach would work well for providing access to office based clients. In this instance the server will be accessed by clients using the SSTP VPN provided by Azure.

This is how the virtual network looked after transferring data from on-premise LAN to Azure:

Install the and configure Azure Powershell

You need to install the Azure Powershell in order to be able to assign your new virtual machine a Static Internal IP Address as all IPs in Azure are dynamic.

Follow the instructions here to install Azure Powershell:

http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/

Set a Static Internal IP address on your new Essentials VM

Because all VMs in Azure are assigned IP addresses automatically we need to ensure that the essentials server has a static IP address so that we can set that server as a DNS target for the virtual network. In Azure this is referred to as a DIP – I have no idea what the D in DIP stands for, so if anyone knows, please let me know!

This will allow the server itself, clients and other virtual machines to function properly within the AD domain.

Join the essentials server to the domain and promote to a domain controller.

You should now have everything in place to allow you to move forward and install Active Directory services and promote your new Windows Server Essentials virtual machine to a domain controller. Depending on the speed of your link this may take a while. For me it took around 20 minutes while AD was upgraded on the existing server and the Windows Essentials machine was rebooted.

At this stage you can continue with the migration just as if it were an on-premise deployment, you may need to plan well ahead if you have lots of data to transfer and do not have access to a fast internet connection to do it with.

For copying the data from the source system I just used Robocopy and was able to maintain at least 5Mb upload most of the time.

Allow anywhere access

Anywhere access is one of the things in Essentials that makes it work so well in Azure. The SSL-VPN means that you need only open ports 80 and 443, which I think is really neat..

A word of warning though, if you are migrating from SBS 2003, some of the existing group polices made it difficult for me to run the anywhere access wizard. If you get problems with the VPN wizard failing, see this post.

After you have successfully run the VPN wizard, you need to assign a static address pool in RRAS administrator. See this document for more details:

http://technet.microsoft.com/en-us/library/dd469667.aspx

Add an additional UPN suffix to local domain(Optional)

I always like to add an additional UPN suffix the the local AD so that users can use the same sign-in information on 365 as their regular resources. See here…

http://support.microsoft.com/kb/243629

Conclusion

Migrating from SBS 2003 to Office 365 and Azure hosted essentials is mostly straightforward. If I was migrating a system with so few users again then I would just fresh install and lose the existing AD, but this was a good opportunity to prove the concept as I will be moving some customer resouces with more sophisticated requirements and greater number of users in the near future and the process will be much the same.

I do have a confession to make though….

I am running Storagecraft Shadowprotect on the VM and sending the data out of Azure back to our own storage running in a co-lo facility near our offices. Why? This is the first real infrastructure that I have run in the cloud that is not on our own hardware where we have complete control over it, having the system backed up to our own servers makes me sleep well at night. Because the upload capacity of Azure is so good it hardly takes any time to run a Storagecraft Backup so I feel OK about it

Office 365: 550 5.7.1 RESOLVER.RST.AuthRequired when emailing a mail enabled public folder

July 1, 2014 by Paulie Leave a Comment

A recent change in Exchange online seems to have caused a problem with mail enabled public folders receiving messages from people outside of the organisation. It has never been necessary with Office 365/Exchange Online to give create permissions to the anonymous or default users , you could instead set the mail flow settings of the public folder to allow anonymous access.

You may see the following bounce message when sending to a mail enabled public folder:

Delivery has failed to these recipients or groups:

Your message wasn’t delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept email from certain senders, or another restriction may be preventing delivery. For more tips to resolve this issue see DSN code 5.7.1 in Exchange Online. If the problem continues contact your help desk.

5.7.1 RESOLVER.RST.AuthRequired; authentication required [Stage: CreateMessage]>’

Of course it is possible and easy to set permissions for the public folder from Outlook to solve this problem, but doing this does not seem to be working for everyone. Some people are reporting success with it, but others not.

Setting the public folder permissions with PowerShell fixes the problem, but I cannot understand why there is a difference.

Setting Offiec 365 Public Folder Permissions with Powershell

In order to fix this problem you have to grant create permissions to anonymous and the default user. The Powershell cmdlet to do this is Add-PublicFolderClientPermission.

After connecting to Office 365 Remote Powershell as described here, you can run the following commands:

Add-PublicFolderClientPermission -identity "\test public folder" -User Anonymous -AccessRights CreateItems
Add-PublicFolderClientPermission -identity "\test public folder" -User Default -AccessRights CreateItems

Once you have added the permission it’s probably best to give it a quick check with:

Get-PublicFolderClientPermission -identity "\test public folder"

Hope this helps.

Grant a single user access to access all users calendars in Office 365

June 5, 2014 by Paulie 2 Comments

If you need to Grant a single user access to access all users calendars in Office 365 this can be achieved by using the Add-MailboxFolderPermission cmdlet.

If you are adding permissions to a mailbox where no access rights exist already then this is straightforward, but if there is already some access rights in place then the command will fail, because there is an existing permissions entry in place.

You can check for the presence of existing folder permissions with the use of Get-MailboxFolderPermission cmdlet.

Finally if you find there is any existing permission in place you can remove it by using the Remove-MailboxFolderPermission cmdlet.

I have combined these three steps have been into the PowerShell script below which will check for an existing permission, remove it if it exists and then add the new access right. This is useful if you want to re-run the script on a regular basis so that it captures new users.

PowerShell script to Grant a single user access to access all users calendars in Office 365

Type in the UPN(User Principal Name) of the user that you want to grant calendar permissions.
Select the permissions level you would like them to have.
Copy and paste the code to a Powershell window and the calendar permissions will be assigned.

The various levels of permissions are as follows:

None – Has no access to the folder.
Owner – Gives full control of the folder. An Owner can create, modify, delete, and read folder items; create subfolders; and change permissions on the folder.
Publishing Editor – Has all rights granted to an Owner, except the right to change permissions. A Publishing Editor can create, modify, delete, and read folder items and create sub folders.
Editor – Has all rights granted to a Publishing Editor, except the right to create subfolders. An Editor can create, modify, delete, and read folder items.
Publishing Author – Can create and read folder items and create subfolders but can modify and delete only folder items that he or she creates, not items created by other users.
Author – Has all rights granted to a Publishing Author but cannot create subfolders. An Author can create and read folder items and modify and delete items that he or she creates.
Nonediting Author – Can create and read folder items but cannot modify or delete any items, including those that he or she creates.
Reviewer – Can read folder items but nothing else.
Contributor – Can create only folder items and cannot read items.
Availability Only – View only availability data
Limited Details – View availability data with subject and location

This should generate output similar to the below:

How to bulk whitelist domains in Office 365 using Powershell

May 21, 2014 by Paulie 7 Comments

How to Bulk Whitelist domains in Office 365

There are plenty of blog posts that explain how to add a mail flow rule in Office 365 to allow you to white list a sender domain, bypassing the 365 spam filtering completely. There is a nice guide on how to achieve that in this blog post by Robert Crane.

I was working with a customer today that had a long list of domains that they wanted to white-list, but the Office 365 admin interface does not provide a facility to enter a list in bulk. So I wrote a PowerShell script that would do the job of creating a transport rule based on a simple list from a text file containing email domains.

Creating a Mail Flow rule to handle many trusted domains.

1. Download the script
2. Create a plain text file containing a list of domains or email addresses. The script will strip the first part of the address to leave only the domain name remaining.
```
nicedomain.com
trusteddomain.com
tachytelic.net
[email protected]
```
3. Connect to Exchange Online using PowerShell. Instructions on how to do that here:
  http://technet.microsoft.com/en-us/library/jj984289(v=exchg.150).aspx
4. Run the script that you downloaded (Add365SafeDomains.ps1)
  1. 1. With Parameters like this:
```
.\Add365SafeDomains.ps1 -ruleName "Safe Domain List" -domainListFilePath "c:\domainlist.txt"
```
    2. Or without parameters and you will be prompted:

Specify a meaningful rule name, this will help you segregate different groups of domains easily.
If you specify a rule name that already exists, the contents of the “SenderDomains” property will be loaded into an array and combined with the new list.
- Duplicates are automatically removed
- The list is sorted into alphabetical order for easier readability the Office 365 Portal to view the rule.
If you specify a rule name that does not already exist, a new rule will be created instead.

The script works by creating an array of domains and supplying that array to the set-TransportRule cmdlet.

Here is the code for the script:

Param(
   [Parameter(Mandatory=$True,Position=1)]
   [string]$ruleName,
  
   [Parameter(Mandatory=$True)]
   [string]$domainListFilePath
)

#Read the contents of the text file into an array
$safeDomainList = Get-Content $domainListFilePath

#Create a new array and remove all text for each line up to and including the @ symbol, also remove whitespace
$newSafeDomainList = @()
$newSafeDomainList += foreach ($domain in $safeDomainList) 
            {
              $tmpdomain = $domain -replace ".*@"
              $tmpdomain.trim()
            }

#If the rule already exists update the existing allowed sender domains, else create a new rule.
if (Get-TransportRule $ruleName -EA SilentlyContinue)
{
  "Updating existing rule..."
  $safeDomainList = Get-TransportRule $ruleName |select -ExpandProperty SenderDomainIs
  $completeList = $safeDomainList + $newSafeDomainList
  $completeList = $completeList | select -uniq | sort	
  set-TransportRule $ruleName -SenderDomainIs $completeList 
}
else
{
  "Creating new rule..."
  $newSafeDomainList = $newSafeDomainList | sort	
  New-TransportRule $ruleName -SenderDomainIs $newSafeDomainList -SetSCL "-1"
}

You can copy and paste the above into your own PowerShell script or download the script here.

If you found the script helpful, please rate the post! 😀

Office 365 Last Logon Date Report / Inactive Account Report

March 21, 2014 by Paulie 20 Comments

I’ve been wanting an excuse to try developing a GUI in power shell for a while so decided to put together this front end which will check the Office 365 last logon date and time for all users and quickly enable you to see which Office 365 Accounts are inactive.

Office 365 Inactive account report script

When you run the script you will be presented with this form:

Enter your Office 365 username and Password and click “Login”.
Wait while the script connects to your Office 365 server and downloads your mailbox information:
Review all of your inactive accounts!

You can sort the list by the last logon date and time or the number of days since last logon by clicking on the column headers.

If the user has never logged in they have their last logon date set to 01/01/2000. This script makes things a little easier than getting too deeply involved in Powershell to discover this useful information.

Download the file from here:

https://www.tachytelic.net/files/Office365LastLogonReport.zip