I wanted to provide a walk-through of what the current set of tools provides in terms of setting up and sharing documents via RMS.  For more detailed information on RMS check out the TechEd 2014 session delivered by Enrique Saggese, a Program Manager on the RMS team.

Deploying RMS for Cloud-Friendly and Cloud-Reluctant Organizations

First thing you need to do is go to the Azure RMS Portal and download the latest RMS application for your device.   https://portal.aadrm.com/  If your company is already using RMS, either on premise or in the the cloud with Azure RMS you will be able to ‘connect’ the RMS client to your existing templates.  The RMS client also seamlessly integrates with the Office 2013 suite.

Outlook Integration:

Office Apps (Word, Excel, etc…) integration:

With the RMS client, you can connect to existing templates created by your administrators either on Windows Servers running the RMS feature or Azure RMS.

In my case above, I have an O365 tenant I demo from and I’ve configured the templates using Azure RMS.  The first time you open the RMS client you’ll see the option to ‘connect to RMS service…’ in the place where you see my existing templates.  Once it’s made the connection from that point on, you’ll see the actual templates available when you use the RMS client.

Now, lets go to the RMS portal and setup our account and download the client.  If your organization is already using Azure Active Directory, then you won’t need to setup a new account – the RMS client will simply start working with your existing RMS setup.

If your organization is already configured to work with Azure AD, then you might see a message like this after entering your email address:

In which case, once you click ‘NEXT’ you will be prompted to authenticate with your credentials associated with that email (assuming it’s a corporate login for example) and you’ll see the following screen where you can download the RMS client to your computer:

Now, if you don’t already have and account you’ll still see a similar screen – you just won’t see the few previous screens that tell you that your company is already configured for RMS.  But still, you’ll be able to download the RMS client to your machine and start using the service.

Once the RMS client is installed you’ll see new context menus when you right click on items.  Let’s create a document in Word and save it on the desktop.  The first option is to “Share Protected” which essentially launches the RMS client and allows you to enter email addresses (LiveID’s, gmail, yahoo, outlook.com, etc… are not accepted at this time) and assign permissions to the recipient.

RMS will protect the document then open Outlook to send the email.

When the recipient receives the email one of a couple things will happen.  If their user account is already in Azure AD (let’s say they are an existing O365 customer which would be the most common scenario), then they will be able to open the document in Word without having to set anything else up.

If the email domain of the recipient is not in Azure AD, then per the email they will be sent out to the sign-in page to create an account.

After they sign-up they will receive an email asking them to continue on to complete the sign-in process.

The recipient will then fill in a few pieces of information:

It takes a few seconds to provision the account then the recipient is passed along to the page where they can download the appropriate RMS client for their platform.

Now when the recipeient opens the protected document they are prompted for the credentials they just created for the RMS client:

The recipient now has ‘view’ only access as given using either the RMS client reader or Word 2013.

Ah, what a beautiful site this is!  With RRAS on Server 2012 R2 and Azure – it’s never been easier to get a Site-to-Site VPN up and running!  Here’s how…

I setup a S2S VPN using this configuration in my lab today and thought I’d throw a quick post together walking through the current configuration for 2012 R2.  I did some searching around on my own for a quick tutorial but wasn’t able to find anything current.  So, here we go.

First things first.  You need the right kind of connectivity from your RRAS internet endpoint to Azure.  Specifically some UDP ports and IP Protocol Type=ESP (value 50).  If these aren’t open on your RRAS internet IP address then the connection won’t work.  So, if you are running this off your home network for a lab like I am – make sure that your internet provider supports this before you get too far down the path.  For me, I’m using ATT Gigapower and have a small subnet of static IP’s.  I assigned one of the static IP’s to the internet facing adapter on my RRAS VM and away it went.

Here’s a good article on what ports you need for VPN for various scenarios.

One tool that I found quite helpful for determining what ports were open/listening was PortQuery GUI.

PortQuery is dead simple to use and effective.  You’ll just want to make sure that the UDP ports are open and listening.

A good utility to use to troubleshoot connectivity from the RRAS server is WireShark.  It’s similar to Network Monitor – but a little easier to use.  If you’re not familiar with packet/network analyzer tools it might be a little much – but it can/will provide some useful information to anyone that is helping you troubleshoot any connectivity issues you might be facing.

Step 1:

• Install Windows Server 2012 R2.
  • You don’t need to install the RRAS components.  The script you will download from Azure later will do all of that for you.  Just get WS2012 R2 running, get all the updates, etc…
  • Configure your network adapters for RRAS.  You will need to two of course.  I simply labeled them “WAN” and “LAN”. 
  • You will want to remove the default gateway from the LAN side interface.  This will ensure any traffic hitting that interface gets routed out the WAN vs going back to your default gateway.  Now, there are other ways to accomplish this – for example, if your existing default gateway has the ability to assign static routes…but for a lab scenario like I have – it was easier to just remove the gateway and configure static routes on all my hosts to point to the RRAS LAN interface when they hit the IP range out in Azure.
  • You will also want to remove some of the ‘bad things’ off the WAN network adapter that can get you into trouble.  Get rid of Client for MSFT Networks and FPR Sharing.   You will also want to go into the TCP/IP IPv4 advanced tab and disable NETBIOS over TCP/IP.  

Step 2:

• Configure your affinity group in Azure.  Azure is a globally dispersed hosting service – where do you want your VM’s to ‘live’?  In the Azure context, these are defined as “datacenters” in “regions”.
• In order to tie VM’s with virtual networks – Azure uses the Affinity Group.  An Affinity Group ties those resources to a specific region.  You probably want to pick the one closest to you if you don’t have a specific preference.
• In Azure on the left hand side menu – click “SETTINGS”.  Now click “Affinity Group” on the menu bar:

• Now we need to define a “Local Network”.  A local network defines the properties of the network where your RRAS server resides – specifically the “LAN” side.
  • In my case, I was using the 192.168.1.0/24 for my LAN. 
  • “1.1.1.1” would represent the WAN IP interface on your RRAS server.

• Now you’ll want to add the hostname/IP address of a DNS server that you want to use.  This DNS server will be added to the VM’s that come online the Azure virtual network we’ll create in a bit.  The significance of this of course is that your Azure VM’s will be able to resolve hostnames across the VPN.  This could be the IP address of an AD Domain Controller across the VPN and/or you could of course bring up a VM in Azure and make it a domain controller in which case you’d make an entry here once you did that so that your Azure VM’s would look to the DC in Azure first for name resolution.

• If you want to install DC’s in Azure – be sure to read this. 

• Now we’ve got the CorpNet side under control as far as Azure is concerned.  Next, we need to configure the Azure Virtual Network.  This diagram is basically what we are going for.  I’ll copy my exact configuration from Azure that I used as well for reference and to match it up to the Visio network diagram.

• Here is my configuration on the Azure side.  You can do something similar or come up with your own.  I just wanted to put it here so you could match it up with the Visio diagram:

• You are going to click NEW –> Networks –> Virtual Network –> Custom Create:

• Now we’re going to set any DNS servers we want our Azure VM’s to connect to (this will be a drop down box and all the DNS servers you created earlier will populate there) and we also want to enable S2S VPN.  Select the local network you created in the drop down.          

• The sky is the limit here.  Do whatever works best for you.  You can create a huge address space and then create any number of custom subnets.  You will need to click the button to add the gateway subnet as well.  This will be the default gateway IP address in your Azure VM’s you assign to this vNet.

• The next step is to create your gateway.  I forgot to take a pre-screen shot so you’ll see the option here to DELETE mine, but yours will say “CREATE”.  :)  It takes some time for the gateway to complete – so now is a good time to grab lunch, pound through some email, whatever…

• Once your gateway is created, you’ll see the gateway IP in big bold on your dashboard.

• Next step is grabbing your shared key.  Use the copy button to get it on the clipboard when needed.

• The next thing you’ll want to do is create a VM that gets placed into the vNet you just created.  You have to be a bit careful here because you need to place the VM in the right virtual network for it to be able to access resources via the VPN we are creating.  You can’t just put it anywhere and expect it to be able to communicate across the VPN.

• The final piece here is finalizing your RRAS configuration.  We’ve already got our server running, dual-homed, with the proper network configuration.  Now we just need to get RRAS installed and get the S2S VPN configured.  Luckily, there’s a script for that. :)  From your S2S VPN dashboard – look in the lower right corner.  You’ll see a link to download the VPN device script.

• Choose Microsoft/RRAS/Server 2012 and download the file.

• This is going to download a .cfg file.  The easiest way I found to edit this is to simply open it in PowerShell ISE.  You can also use something like Notepad++ to make editing easier.
• You’ve got a few variables that you need to play with here.  You’ll have to copy/paste in a few things custom to your environment to make the VPN configuration on RRAS work properly.
• I opted for the find/replace all option in PowerShell ISE.  You don’t need the brackets <> – you can remove those when you paste the IP addresses into the script.

• Here are your variables you’ll need to grab the IP info for:

• <SP_AzureGatewayIpAddress>: This is the BIG number on the dashboard for your S2S VPN in Azure.
• <SP_AzureVnetNetworkCIDR>:100: This one you have to be careful with.  Azure uses a few more addresses in a standard subnet than usual.  Let’s say in a /24 or 255.255.255.0 subnet – you get to use 252 of those address.  Azure takes 3 addresses, not just two.  So, the 252 is really 251.  This is the number you use in place of the “100” that they show in the sample variable in the script.  So, to find this – go to the ‘configure’ tab in your S2S VPN and take a look at what you have in the first line of the address space.  This is what you’ll use to populate this in the script.  In this specific example it would be:

• IPv4Subnet @("10.0.0.0/24:251")

• -SharedSecret <SP_PresharedKey>: This is an easy one.  Just copy and paste the shared key we created back a few steps ago.
• Now, save the script and run it.  You will probably see the same error message as I did – it just means that you need to go to the RRAS console and start the service on the server.  For whatever reason in my script – it didn’t restart it.  No biggie.

• Now from the RRAS console, you should see the S2S VPN connection named for your IP Gateway in Azure.  Right-click and choose CONNECT.

• Now, come back over to the Azure portal and go back to your S2S VPN dashboard and click CONNECT on the bar at the bottom of the screen: (mine says disconnect but you get the idea…)

• Once that is done you should see the connection come up on both sides and you can start moving traffic across the VPN!!
• One easy way to test connectivity is to log into your Azure VM that you created in the S2S VPN network and ping the LAN IP address of your RRAS server.  If you can’t ping that – then you’ve got something messed up somewhere. 
• Your Azure VM’s will pickup the DNS IP you assigned earlier so provided communication is working and firewalls are configured properly, you will be able to domain join those VM’s since they will have name resolution to your DNS servers as soon as they boot up.

One thing to be aware of.  Depending on your setup, you may need to configure a static route for other computers on your network to see across to Azure.  For example, if an Azure VM with an IP of 10.0.0.4 tries to ping across the VPN to a machine with an IP address of 192.168.1.50, without a static route on 192.168.1.50 to tell it how to get back over to 10.0.04 – the ping will time out.

On the 192.168.1.50 machine you’d need to add a persistent route with the command:

route add –p 10.0.0.0 netmask 255.255.255.0 192.168.1.1

Of course, 192.168.1.1 is the LAN IP of the RRAS server or any other router that you may have that knows the route to get over to the 10.0.0.0/24 network.

GOOD LUCK!!

I’m in the process of building out new scenario’s for my EMS focused lab.  RemoteApp seemed to be a natural fit here – especially the “hybrid” scenario which leverages your Azure AD/Hybrid Identity.  The endgame here is to be able to access your published applications on any device (iPad, BYOD Windows or MAC machine, etc…) using your AD credentials (ie; SSO).  In my lab, I’m even using the MFA features available in Azure so I can force multi-factor authentication on users access applications via RemoteApp. 

To whet the appetite…here’s an example – I’ve published the SCCM console via RemoteApp.  Since the deployment is Hybrid – these apps can now talk back to my on-premises services via a dedicated site-to-site VPN you’ll configure as a part of the RemoteApp configuration process.  I’m now able to download the Remote Desktop App for the iPad and connect to my applications.

Let’s get started…

• You’ll need to sign up for the RemoteApp preview if you haven’t already.  As of now, it won’t just show up in your Azure subscription.  It may take some time to get approved so don’t plan on clicking it and starting this process within a few minutes…

• http://azure.microsoft.com/en-us/services/preview/

• The next thing you want to make sure you have a handle on is what Azure AD is the default directory for your subscription.  This is what RemoteApp will use in the hybrid scenario.  This is important because, as you’ll see, the users that you will want to give access to the RemoteApp’s that you publish will come from your Azure AD.  If you are – or are planning – to do directory synchronization from your on-premises AD to Azure then it’s important that you ensure that Azure AD is the default.

• To do this – navigate to the settings section (left hand side of Azure admin portal at the bottom) and click on subscription.  The click on the “edit directory” at the bottom of the page to see which Azure AD your subscription is pointing to.  If it’s not pointing to the one where your users are – then you’ll need to change it.

• Next, for the hybrid scenario you’ll need to make sure that your environment can support a site-to-site VPN connection from Azure.  If you are building this out in a lab like I am (ie; your house/residential internet) then you’ll need to make sure you have the right ports open to make this work.  I am running mine out of my home network as well – but I use ATT Gigapower and I have a small subnet of static IP’s that allowed me to create a RRAS server and pin up a VPN to Azure with no issues.  You can check out my recent post on how to configure a S2S VPN using RRAS and Azure.

• There’s a link in the early part of the above blog post that shows the ports you need to have open as well as some tools you can use to ensure the right ports/protocols are working remotely.  It’s easiest to use an Azure VM to test from since its obviously outside your network and can simulate accurate remote connectivity.

Alright, let’s get started on the RemoteApp configuration in Azure…

• These parts have been pretty well covered and I’ll link a couple other blog posts here to follow their step-by-step instructions since they are well done and accurate. (no need to recreate the wheel here).  I just wanted to make sure that everyone understood that there are VPN considerations here as well as understanding which AD RemoteApp will point to and how to change that if it’s not set to how you require for your hybrid configuration to work properly.

• Step-by-Step Part 1
• Step-by-Step Part 2
• Official RemoteApp Hybrid site on Azure