Concluding our 3 part End of Support for Windows Server 2003 series, Eric Mills and I highlight some of the key concerns small to midsize businesses need to be aware of if they are still running Windows Server 2003 in their environment.

Eric Mills and yours truly kick off a new 3 part series today as we discuss the upcoming End of Support for Windows Server 2003. Tune in for part 1 as we discuss the reasons why you should migrate now to a supported operating system before its too late.

We’re hosting another of our IT Camps on Microsoft Azure and how to extend your datacenter into the cloud. It’s a free, full-day of learning, including hands-on-labs and great resources for further investigation.

The following article is part 4 of our many-part series, “Hybrid Cloud for IT Pros”. Click HERE often for the ever-growing full list of articles in this series.

At my IT Camp events, when discussing this topic, I’ll often ask my IT Pro friends in attendance the following questions; usually with the following results:

“How many of you have played with Windows Server Backup, the built-in file backup and recovery utility?”About 50%-75% of the hands go up.

“How many of you are using Windows Server Backup as your main server file-system backup tool?”Maybe one or two hands go up. And we all laugh.I’m not surprised! It’s a very simple tool, and maybe didn’t do all we need for things such as long-term archiving and off-site storage.. so we went with other value-add providers. But still, if you want to simply create a backup schedule and save multiple recovery points, Windows Server backup is still a nice solution.

Wouldn’t it be great if there were a way to take that simple capability and, rather than storing backups to another local storage device, we stored directly into the cheap and always-available cloud storage that is Microsoft Azure?

“Yeah! I’d love that!”

Your wish: GRANTED.

Azure Backup is Microsoft’s Windows Server Backup – cloud-ified. At the heart of it it involves an Azure subscription, a storage account, a credential to allow the service to trust the server (or client), and an agent installed on your local server (or client).

“Kevin.. you keep saying ‘(or client)’. Are you saying that this Azure Backup can also backup files from Windows Client operating systems?”

7.In ENDPOINTS, in ENTER OR SELECT A VALUE, select REMOTE DESKTOP, and then click the Next arrow.

8.Click the Complete icon.

a.The virtual machine will take a few minutes to create. Depending on the load this may take between 5 and 25 minutes.

b.Wait for the new virtual machine to finish before proceeding.

Connect to the new Linux VM using SSH and RDP

In this task, you will use a Secure Shell (SSH) connection to manage Linux01 and install both the desktop and RDP protocol server. This step can take upwards of 30 minutes due to installation times. You can choose to wait, or start the installation, move on, and then complete this step at a later time.

a.Using Internet Explorer, download and extract https://itcmaster.blob.core.windows.net/fy15q3/AzureManagement.zip to your create an \AzureManagement folder (either at the root of C:\, or on your desktop).

Bingo. And as of December, 2014 it also supports backup and restore of files on Windows Client (7, 8, 8.1 and on up) operating systems.

Here’s what we’ll do in this Step-by-Step guide:

Configure the Backup Vault

Download the Vault Credentials

Download and Install the Backup Agent

Register the Server

Configure the Backup Schedule

Backup Now

Navigate the Recovery Vault

Restore a Deleted File

Remember: If you just want to try this out without purchasing or using an existing Azure subscription, you can easily set up a free trial.

Configure the Backup Vault

Note that, to start, you might want to be doing these steps from the server or workstation that you want to configure for backing up files. You’ll be downloading credentials and agent, installing the agent, and registering the machine against your Azure subscription, all from that server or workstation, so you may as well start these steps from that machine.

Select Recovery Services, and click New (the “+”mark) at the bottom left of your browser. This will contextually place you into the New / Data Services / Recovery Services area.

Select Backup Vault, and then Quick Create.

Your only two things to configure here are to give your vault a useful name, and to choose where in the world you want to have it stored. Note: You may notice that not all of our data center regions support hosting backup vaults. The list of regions may change over time.

Click Create Vault, and after about 10-15 seconds you’ll have your new backup vault ready to use.

By clicking on the name, you’ll enter into your vault’s quick start page.

Download the Vault Credentials

In the first versions of Azure Backup, establishing the trust between the vault and the server to be backed up required generating and installing a certificate, exporting it, and uploading it to the vault. More recently, however, we’ve made it very easy for you. You’ll simply download the vault credentials from within your account, and that file will be used to establish the trusted connection; either for initially registering the server or workstation, or to recover items to a new machine.

On the quick start page, click Download vault credentials. You will be prompted to open or save a file of type .VaultCredentials.

Save it somewhere you’ll remember, on your machine to be backed up. Note: Treat this file with care. It’s a file that you don’t want to let get into the wrong hands.

Download and Install the Backup Agent

On the quick start page, click the link to download the backup agent that you require.

Notice that the same agent you can use to natively backup a workstation or server’s files is also the one used by System Center Data Protection Manager (SCDPM), which also can backup to or restore from Azure.

Save the MARAgentInstaller.exe, and then run it later. Or simply run it at this point if you’re already on the machine you want to backup files from.

I choose to run it from right here. You will have some very basic configuration choices when you install the agent.

For my needs, I’m going to just take the defaults, and don’t have any special proxy to get me to/from the Internet. Notice that the agent installation will also install any required components (.NET Framework 4.5) or software (Windows PowerShell) that might be missing.

When the installation is done, you can either close the installer or “proceed” to the “registration”. I’m going to proceed.

Register the Server

When you do that (or when you open the agent for the first time), you’ll be asked to provide the vault credentials file.

Browse to and select the file you saved earlier, then click Next.

On the Encryption Setting page, you’ll either generate, or enter your own Passphrase.

I choose to have the tool generate a long passphrase for me, and I’ll just save it to my desktop folder for now.

Leaving the “Launch Microsoft Recovery Services Agent” checkmark checked and clicking Close will launch me into the recovery agent.

Note the options in the Actions pane on the right. We’ve already registered the server, but as the little alert in the main pane reminds us, we haven’t yet scheduled anything to backup. So let’s do that now.

Schedule your Backups

I have a folder full of very important stuff. For this demonstration, it’s right on my C:\ drive in the “Very Important Stuff” folder, with an important file called An Important File.txt

In the Microsoft Azure Backup tool, in the Actions pane, I will click on Schedule Backup.

Clicking Next on the Getting Started page brings me to the Select Items to Backup page.

This is what I use to add, browse to, and select folders or items to backup. Notice that I could also use this to exclude certain files by file types.

I’ve selected the C:\Very Important Stuff folder, which is all I need to backup for now. Click Next.

On the Specify Backup Schedule page, notice that I can choose to do my backups daily at a certain time, or weekly, being able to select the days and times to perform the backup.

I’ll just do my backup daily at 4:30am. Click Next.

On the Select Retention Policy page, we have some pretty flexible options for retaining our backed-up data for longer periods of time. In my case, not every daily backup needs to be saved for several years, but maybe just the backup that I take the Saturday of the last week of March, which I want to save for 10 years.

Click Next.

On the Choose Initial Backup Type page, I can choose to do my first backup of my files automatically over the Internet, or in an “offline” way, automating the pull of the first set of data from an existing Azure storage location. For our simple sample, we’ll just do our first backup over the Internet. Click Next.

And on the Confirmation page, I verify that all is as it should be. Clicking Finish creates my backup schedule.

Backup Now

Note: You haven’t yet launched any backup! If I left it all now, the next backup would happen based on my schedule. But I’m going to click the “Back Up Now” option in the Actions pane.

On the resulting Confirmation page, I click Back Up. And then I can click Close at any time, because the job has been launched and will run for you in the background – even if you close the Microsoft Azure Backup console.

But I’ll leave the console open and watch the status of my job change…

…and in fairly short order (because this was a pretty small backup), I see this…

And I’m quite relieved that my very important stuff is now safely tucked away in my cloud recovery services backup vault.

Navigate the Backup Vault

Back in your Azure subscription and in the Recovery Services section, let’s look into my SampleBackupVault and see what we can see there…

On the DASHBOARD tab, I can see that I have one “server” registered, and currently 0 GB currently protected. (It was a pretty small file, so I’m not surprised that it didn’t register here.)

On the REGISTERED ITEMS tab, I can see my one machine of type “Windows server” currently listed and registered.

Notice that this is also where I could delete any old or no-longer-needed server registrations.

On the PROTECTED ITEMS tab I can see some basic information about what I’ve protected; a file folder currently with only one recovery point available.

It also shows what the most recent recovery point and time are.

Restore a Deleted File

Oh no! Someone deleted my file! (Hint: It was me.)

No worries! Go back into the Microsoft Azure Backup console and click Recover Data in the Actions pane.

On the Getting Started page, notice that I can specify if I’m currently on the machine where the backup was originally taken (and therefore is already registered with the Backup Vault), or if I’m on a new machine that doesn’t yet have the vault credentials – in which case I’d be given the opportunity to point to a downloaded .VaultCredentials file.

Since I’m on the machine where the backup was taken, I’ll just click Next.

On the Select Recovery Mode page, I can choose to either Browse for my files, or search for them.

I would pick search if I knew there were a very large list to go through. But in my case, it’s just one file, so I’ll just browse. Click Next.

On the Select Volume and Date page, you use the drop-down to pick the volume from which your backup was taken, and then you’re presented with a calendar with some dates in bold representing points in time when you’ve completed past backups.

In our sample, I’ve only done the one backup, so that’s the only point I can recover to. I’ll select it, and click Next.

On the Select Items to Recover page, I can browse to my Very Important Stuff folder and see the files that were backed up from it.

I’m happy to see that my important file is there, so I’ll select it and click Next.

On the Specify Recovery Options page, I have some choices about whether or not I want to restore to the original location, or how to handle duplicates. I can even choose to restore (or not) the Access Control List (ACL – the security permissions) that were associated with the original file.

I’ll leave these defaults and click Next.

I verify that all looks good on the Confirmation page, and click Recover. The recovery starts, and I can close this window because the recovery job is now running for me.

Back in the Microsoft Azure Backup console I can see that my recovery job has completed successfully…

…and.. Hooray! My file is back!

So.. that’s about it!

---

What do you think? Go ahead and share your comments / questions / concerns / rants in the blog comments.

The following article is part 3 of our many-part series, “Hybrid Cloud for IT Pros”. Click HERE often for the ever-growing full list of articles in this series.

“Hey Kevin, I’d like to take advantage of putting application servers up in a virtual network in Azure. But I need a domain controller for my application to work. Can I put one in my virtual network?”

Absolutely! There’s no reason you can’t build a server, install AD Domain Services, and have it either as the new domain controller in a new forest, or as another domain controller in an existing forest – provided you can get to the other domain controllers through Site-to-Site VPN Gateway or ExpressRoute.

As a matter of fact, in our current set of content for our US DX IT Camps happening across the country, our Hands-on-Labs have our guests using their own (or a trial) Azure subscription to create a network and then populate it with a Domain Controller (among other machines). If you want to try out just building a Domain Controller on a virtual network in Azure, I suggest you run through at least the first two of our labs:

Appendix

In this task, you will use Windows PowerShell to install and configure Active Directory on DC01. To perform this task, you will use Windows PowerShell ISE as an Administrator.

To connect an RDP session to your DC01virtual machine:

In the Azure management portal, click VIRTUAL MACHINES, click DC01, and then click Dashboard. On the bottom bar, click CONNECT, and then click Open. Click Connect.

When prompted, log on as sysadmin using Passw0rd! as the password. Click yes.

From within your RDP session to DC01:

Open a web browser on DC01 to Browse tohttps://itcmaster.blob.core.windows.net/fy15q3/ADProvisionScriptv2.txtNOTE: The above URL is Case Sensitive!

Click on the text then press CTRL-A to select all text – Then Click CTRL-C to copy it to your clipboard. NOTE: you can just click OK to any security warnings you get

On DC01, Click Start – type Windows PowerShell ISE, Right click on “Windows PowerShell ISE” and select Run as administrator. NOTE: you must run this elevated! Select Yes on the User Access Control Popup.

From PowerShell ISE menu select File – New – Click on line 1 of Untitled1.ps1 and then press CTRL-V to paste in the script.

Press CTRL-A to select all of the script and then press F8 to run the selected script.DC01 will automatically restart to finish installing AD.BE PATIENT! This process takes several minutes.

After the restart, reconnect an RDP session to DC01 and confirm AD and DNS are running on DC01 (Server Manager should list Active Directory tools)

From Server Manager / Tools, you should be able to open DNS and other Active Directory tools such as AD Users and Computers)

---

Connect your PowerShell to Azure

Before you can manage virtual machines from PowerShell on your local administration station you need to download the tools.

You will now need to connect Microsoft Azure PowerShell to your Azure subscription. In your PowerShell session type the following command:

Add-AzureAccount (Press ENTER)

Enter your Azure Subscriber ID and Password.NOTE: If you do not know your SubscriberID: Login to the Azure portal http://manage.windowsazure.com click on your email address in the upper right corner, Click View My Bill. This will list all subscriptions for the current logged in user. Click on the subscription you want to use, then scroll down so see your Subscription ID listed on the right.

Lab 5: Building Application Workloads – Deploy Data Access App

Configure endpoints for WEBFE01

In this task, you will configure the required public endpoint mappings for WEBFE01.

Perform the following tasks in the Azure management portal.

In the Azure management portal, click in VIRTUAL MACHINES.

Click WEBFE01, and then click ENDPOINTS.

Click ADD.

In ADD ENDPOINT, click the Next arrow.

In Name, select HTTP, and then click the Completed button.

You will have to wait for the endpoint to be created then continue

Click ADD.

In ADD ENDPOINT, click the Next arrow.

In Name, select HTTPS, and then click the Completed button.

You will have to wait for the endpoint to be created then continue

Click ADD.

In ADD ENDPOINT, click the Next arrow.

In NAME, type Custom5000.

In PUBLIC PORT and PRIVATE PORT, type 5000, and then click the Completed button.

You will have to wait for the endpoint to be created then continue

Click ADD.

In ADD ENDPOINT, click the Next arrow.

In NAME, type Custom5001.

In PUBLIC PORT and PRIVATE PORT, type 5001, and then click the Completed button.

Click Dismiss Completed in Azure Portal after all are done

Configure firewall ports for WEBFE01

Next, you must enable WEBFE01 to communicate internally within the service. While general IP connectivity is provided by DHCP, both servers are workgroup members and have the public firewall profile enabled. In this task you will open firewall ports and enable PING traffic on WEBFE01.

Perform the following tasks in an RDP connection to WEBFE01.

In your RDP session to WEBFE01, open Server Manager.

Click Local Server.

Next to Windows Firewall, click Public: On.

In Windows Firewall, click Advanced settings.

In Windows Firewall with Advanced Security, click Inbound Rules, and then click New Rule.

In Rule Type, click Port, and then click Next.

In Specific local ports, type 80, 443, 5000, 5001, and then click Next.

On the Action page, click Next.

On the Profile page, click Next.

In Name, type Allow WebApp, and then click Finish.

In Windows Firewall with Advanced Security, click Inbound Rules, and then click New Rule.

In Rule Type, click Custom, and then click Next.

On the Program page, click Next. (All programs should be selected)

On the Protocol and Ports page, in Protocol type, select ICMPv4, and then click Next.

In this task, you will use Windows PowerShell remoting to install Internet Information Services on WEBFE01. To perform this task, you will use standard Windows PowerShell remoting and administration commands; however, you must first install the Windows PowerShell remoting self-signed certificate installed in your WEBFE01VM. This is because Windows PowerShell remoting relies on HTTPS connections by default.

Establish an RDP session to your SQL01Server:

In the Azure management portal, click VIRTUAL MACHINES, click SQL01, and then click Dashboard. On the bottom bar, click CONNECT, and then click Open. Click Connect.

When prompted, log on as sysadmin using Passw0rd! as the password.

Click yes.

From within your RDP session on SQL01:

Click on the Folder on the task bar to open Computer. Double-Click Data (C:) Click Home | New Folder type AzureManagement press Enter. You can then close the computer window and the Server Manager window to continue.

Using Internet Explorer, download and extract https://itcmaster.blob.core.windows.net/fy15q3/AzureManagement.zip to your SQL01 server in the C:\AzureMangement Folder NOTE: The above URL is Case Sensitive!NOTE:: You can just click OK to any security warnings you get

Download https://itcmaster.blob.core.windows.net/fy15q3/AzureManagement.zip by typing the URL into the address bar on your SQL01 server. Click Save as then save to C:\AzureMangement Folder

Using File Explorer open the c:\AzureManagement folder, right-click on the AzureManagement.zip file; select Extract All. Change the path to C:\ then click Extract. Close “Local Disk (C:) window. You should have a window up still that is showing you C:\AzureManagement\

On SQL01, in Server Manager, on the Tools menu, click Windows PowerShell ISE.On the View menu, click Show Scripting pane.

Install the Azure PowerShell Extensions on SQL01:

Run the C:\AzureManagement\WindowsAzurePowerShell.3f.3f.3fnew.exe file to install Azure Powershell Extentions

We now need to enable Azure PowerShell commands by clicking the run pane (bottom) type the “Import-Module Azure” command then press <ENTER>

Import-Module Azure

From the File menu choose FileOpen, and open the script file C:\AzureManagement\Remote PowerShell Script Configuration.ps1.

Select/Highlight the script lines under Part 1, and then press F8 to execute the selected lines.

In the presented web page, log on using your Microsoft Azure account, and then download the PublishSettings file that is presented.

Save the PublishSettings file in the C:\AzureManagement\ folder on the computer.

In the script file, in part 2, replace the text ##Your Script File Path Here## with the full path to your downloaded file, such as “C:\AzureManagement\Free Trial-6-4-2014-credentials.publishsettings”.NOTE: If there are spaces in your file name, you will have to wrap the path and filename in quotes (“) as shown in the example

Highlight the script under Part 2, and then press F8

You should see basic information on your subscription in the output.

Highlight the script under Part 3, and then press F8. When prompted, type your unique ID.You will now have installed the certificate used by the WEBFE01 VM, which will enable remote Windows PowerShell access.

In the Windows PowerShell command area, type the following command, and then press ENTER. Replace <ID> with your unique identifier.

You are now presented with the list of ports that are open on WEBFE01. Using the output of the command above, identify the port used for Windows PowerShell.

In Windows PowerShell (or in the PowerShell window of ISE), type the following command, and then press ENTER. Replace <ID> with your unique identifier. Replace <PORT> with the Windows PowerShell port from the previous command output.

In the Password dialog box, type Passw0rd!, and then click OK. Note: if you changed the username and password when you created the machine, you will have to use the username and password you used to create the machine.

In Windows PowerShell, type Hostname, and then press ENTER.

Notice that you are now in a Windows PowerShell session on your WEBFE01 VM from SQL01.

In Windows PowerShell, type the following command, and then press ENTER. This will install a full IIS server on WEBFE01.

Wait for the command to complete before proceeding. BE PATIENT. It takes several minutes.

In Windows PowerShell, type the following command, and then press ENTER. This will restart IIS

Iisreset

Wait for the command to complete before proceeding.

On your Local Laptop, using Internet Explorer, navigate tohttp://itcservice<ID>.cloudapp.net where <ID> is your unique identifier.You have now connected to your running web server and are ready to hand off this environment for installation of your company’s software.If you cannot connect, wait 2 mins and try the IISReset again. if that still does not work, check to make sure your firewall parts and endpoints were not skipped or configured incorrectly.

Deploy and test the Contoso Data Access sample site

In this task, you will deploy a sample site. The sample web site simulates the types of tasks the Contoso production application performs, and will prove that the Azure infrastructure meets the base technical requirements of the production system.

Perform the following tasks in RDP sessions to WEBFE01.

Switch to the RDP session for WEBFE01.

Using File Explorer, navigate to c:\inetpub\wwwroot.

Delete all files and folders in this folder.

Using File Explorer, navigate to Navigate to C:\AzureMangement\Website.

Copy all Files and folders from C:\AzureMangement\Website to C:\inetpub\wwwroot. The global.asax file should be directly in the C:\inetpub\wwwroot folder, not a subfolder.

Open the Web.Config file in Notepad, and then locate the <connectionStrings> … </connnectionStrings> section.Edit the section so that it reads as follows:

On your Local workstation, using Internet Explorer, navigate to http://itcservice<id>.cloudapp.net.NOTE: You may have to refresh your browser.

Under Data Management Login, type 12345, and then click Login.

Click Product Listings.Be patient. It takes several seconds to spin up the web services and the SQL database the first time.The result set indicates the web application is communicating with the hosted SQL database correctly.

Congratulations! Play around with the various portions of the web site, and verify that you have full SQL Server connectivity.

When you’re done with the labs, don’t forget to shut down your virtual machines from within the Azure Portal, so that you’re not using up compute/hour $$’s.

Lab 4: Building Application & SQL Workloads

Create a new web server virtual machine from the Microsoft Azure management portal

In this section you will create a new virtual machine to host the web application. You can create this VM using quick create; however, that will not enable you to specify the service or storage, and will create separate storage and services for this VM. You will use the gallery option to ensure you can specify the storage and services for the machine.

Perform the following tasks in the Azure management portal:

Click VIRTUAL MACHINES located on the left menu of the Azure management portal.

Click +New to CREATE A VIRTUAL MACHINE.

Click COMPUTE, click VIRTUAL MACHINE, and then click FROM GALLERY.

In Choose an Image, click Windows Server 2012 R2 Datacenter, and then click the Next arrow.

Create a new virtual machine using the values in the following table, and then click the Next arrow.

Configure SQL Server System Defaults

While the web server is being created, let’s go setup some defaults for SQL Server. You would never want to store SQL Data on the system drive, so the first thing we will do is add an additional disk that will be used for holding the SQL Server Data. We will create a single simple drive but you could create multiple drives and use storage spaces as an alternative. See the Lab Appendixfor details.

Perform the following tasks in the Azure management portal.

In the Azure management portal, click VIRTUAL MACHINES.

Click SQL01. Click Dashboard. On the virtual machine Dashboard page for SQL01, click the Attach button (chain icon) located on the bottom navigation toolbar and select Attach Empty Disk. Complete the following fields on the Attach an empty disk to the virtual machineform:

File Name: sql01-sql01data

Size: 50 GB

Host Cache Preference: None

Click the Check Mark button to createand attach the new virtual hard disk to virtual machine.

Now let’s connect a remote desktop session to SQL01

On the SQL01 virtual machine Dashboard tab, click the Connect button located on the bottom toolbar (far left icon) and click the Open button to launch a Remote Desktop Connection to the console of this virtual machine. Click Use another account to login at the console of your virtual machine with the local credentials defined above. Follow the prompts to continue connecting

Click No on the Networks Prompt to connect to other devices.

Now from the Remote Desktop console of SQL01we’ll create a new partition on the additional data disk attached above and format this partition as a new F: NTFSvolume. After formatting this new volume, you’ll create following folders:

Inside Computer Management select Disk Management. An “Initialize Disk” window will pop up, make sure the new disk is selected and click OK.

Right click unallocated space on Disk 2 and select “New Simple Volume…” Click Next: then Next for the Specify Volume Size. The drive letter should be preconfigured to “F”, click Next:

Change the Volume Label to DATA and click Next: Click Finish.NOTE: If you get a Microsoft Windows popup asking you if you want to format, you can just close it (we are already formatting the disk). Once you see the new F: drive in the upper volume window you can close the computer management window and continue.

Click on the Folder on the task bar to open Computer. Double-Click Data (F:) Click Home | New Folder type MSSQL press Enter. Press Enter again to drill down to the MSSQL folder then repeat the process to create the remaining folders (DATA; LOGS; BACKUP) You can then close the computer window and the Server Manager window to continue.

Open SQL Server Management Studio from the Start Screen and update default folder locations to the F: volume. Tip! On the Windows Start Screen, you can quickly find the application tile for SQL Server Management Studio beginning to type the name of this application to automatically search for matching tiles.

Check the database Test, and then in the Database role membership area, check DB_datareader and DB_Owner.

Click Script at the top of the dialog to see what the Powershell would be to create the user and set permissions. It will be displayed in a tab behind the dialog.

Click OK.

Configure firewall ports for SQL01

Next, you must enable WEBFE01and SQL01 to communicate internally within the service. While general IP connectivity is provided by DHCP, both servers are workgroup members and have the public firewall profile enabled. You will enable SQL Server traffic and PING traffic inbound on SQL01.

Perform the following tasks in an RDP connection to SQL01.

In your RDP session to SQL01, open Server Manager:

Click Local Server.

Next to Windows Firewall, click Public: On.

In Windows Firewall, click Advanced settings.

In Windows Firewall with Advanced Security, click Inbound Rules, and then click New Rule.

In Rule Type, click Port, and then click Next.

In Specific local ports, type 1433, and then click Next.

On the Action page, click Next.

On the Profile page, click Next.

In Name, type Allow SQL 1433, and then click Finish.

In Windows Firewall with Advanced Security, click Inbound Rules, and then click New Rule.

In Rule Type, click Custom, and then click Next.

On the Program page, click Next. (All programs should be selected)

On the Protocol and Ports page, in Protocol type, select ICMPv4, and then click Next.

On the Scope page, click Next.

On the Action page, click Next.

On the Profile page, click Next.

In Name, type PING, and then click Finish.

Disconnect from the SQL01 RDP session.

Confirm Connectivity to SQL01 From WEBFE01

Next, let’s make sure we can successfully connect to SQL01from our Web Server.

Download https://itcmaster.blob.core.windows.net/fy15q3/AzureManagement.zip by typing the URL into the address bar on your WEBFE01 server. Click Save as then save to C:\AzureMangement Folder NOTE: The above URL is Case Sensitive!

Using File Explorer Open the c:\AzureManagement folder, right-click on the AzreManagement.zip file; select Extract All Change the path to C:\ then click ExtractClose “Local Disk (C:) window. You should have a window up still that is showing you C:\AzureManagement\

Open with notepad and copy the contents of the C:\AzureManagement\Test Database Connectivity.txt (Test Database Connectivity) file to your clipboard, and then on WEBFE01, in Windows PowerShell ISE paste in the Script pane.

NOTE: If you changed the computer name, username or password you will have to change the script to change the defaults at the top of the script

Click the play button, or press F5 to run the script.

The output of the script is a small set of system data which indicates you can communicate with the SQL Server instance on SQL01.

Lab 3: Working with Identity

Azure Active Directory is a service that provides identity and access management capabilities in the cloud. In much the same way that Active Directory is a service made available to customers through the Windows Server operating system for on-premises identity management, Azure Active Directory (Azure AD) is a service that is made available through Azure for cloud-based identity management. Azure AD can be used as a standalone cloud directory for your organization, but you can also integrate existing on-premises Active Directory with Azure AD. Some of the features of integration include directory sync, password sync and single sign-on, which further extend the reach of your existing on-premises identities into the cloud for an improved admin and end user experience.

When prompted, change the password to Passw0rd! and then click Update password and sign in.

You will see a message “No subscriptions found.” This is expected. The user is not permitted to manage subscription level details.

Close Internet Explorer.

Configure and test the AADSync Service

In this task, you will configure Windows Server 2012 R2 and create a new user to test your synchronization when you enable DirSync, and then perform an initial sync to populate your Azure Active Directory service with copies of your local user accounts.

Click the Domain that synchronized, and then click the Users tab and look for the user you created earlier. You should eventually see the user you created in Active Directory on DC01 now having been synchronized to your Azure Active Directory.

Implementing Multi-Factor Authentication

Multi-factor or two-factor authentication is a method of authentication that requires the use of more than one verification method and adds a critical second layer of security to user sign-ins and transactions. It works by requiring any two or more of the following verification methods:

Something you know (typically a password)

Something you have (a trusted device that is not easily duplicated, like a phone)

Something you are (biometrics)

The security of multi-factor authentication lies in its layered approach. Compromising multiple authentication factors presents a significant challenge for attackers. Even if an attacker manages to learn the user's password, it is useless without also having possession of the trusted device. Conversely, if the user happens to lose the device, the finder of that device won't be able to use it unless he or she also knows the user's password. Azure Multi-Factor Authentication is the multi-factor authentication service that requires users to also verify sign-ins using a mobile app, phone call or text message. It is available to use with Azure Active Directory, to secure on-premise resources with the Azure Multi-Factor Authentication Server, and with custom applications and directories using the SDK.

In this task, you will configure Multi-Factor Authentication (MFA) with Microsoft Azure. To complete this module fully, you need to have a phone which can send and receive text messages or calls. You will configure this lab to use your phone as a second authentication factor this is done via replying to a system-generated text or voice message.

We will start by enabling the MFA service:

Using Internet Explorer on your local workstation, navigate to manage.windowsazure.com.

Log on using your tenant account.

In the Azure portal, on the column, scroll down and click ACTIVE DIRECTORY.

Click MULTI-FACTOR AUTH PROVIDERS, and then click CREATE A NEW MULTI-FACTOR AUTHENTICATION PROVIDER.

In NAME, type Contoso-MFA, ensure the correct subscription is selected (If you have multiple subscriptions tied to your live ID).

For directory select Contoso-AZ-Directory and then click CREATE.

o

Testing Multi-Factor Authentication

In this task, you will test multi-factor authentication. Ensure you have the phone readily available as you will have a limited time to receive and reply to the text message generated by Microsoft Azure.

Lab 2: Building Workloads

Azure virtual machines give you the flexibility of virtualization without spending the time and money to buy and maintain the hardware that hosts the virtual machine. However, you do need to maintain the virtual machine -- configuring, patching, and maintaining the operating system and any other software that runs on the virtual machine. In this lab you are going to deploy 2 virtual machines into Azure for the two workloads of identity and database. You will create these two virtual machines:

A Domain Controller (DC01)

A SQL Server (SQL01)

Deploy a domain controller in Microsoft Azure

In this task, you will deploy a new virtual machine(VM) to function as a domain controller in your newly created virtual network created in Lab01. As you provision the virtual machine you will leverage a custom script extension which contains PowerShell code to install Active Directory as a part of the provisioning process. Custom Script Extensions can automatically download scripts and files from Azure Storage and launch a PowerShell script on the virtual machine. These scripts can be used to install additional software components, and in this lab it will install Active Directory Domain Services and create the ContosoAzure.com forest. Like the any other VM extensions, Custom Script Extensions can be added during VM creation or after the VM has been running. During the last portion of the lab you will also configure the AD service as the DNS server for the virtual network you created in Lab 1, and you’ll assign it a static IP Address (Technically speaking this is a DHCP reservation in the subnet but it will be referred to as a static IP pretty much everywhere in Azure documentation.)

Perform the following tasks in the Azure management portal:

In the left column, find and select VIRTUAL MACHINES.

Click NEW (Plus “+” Sign) located at the bottom of the Azure management portal

Click COMPUTE, click VIRTUAL MACHINE, and then click FROM GALLERY.

In Choose an Image, click Windows Server 2012 R2 Datacenter, and then click the Next arrow.

Create a new virtual machine using the values in the following table. Please note: You can user your own username and password, just make sure to remember it!

The virtual machine will take several minutes to create. Depending on the load this may take between 5 and 25 minutes.

You will return to complete the rest of the DC networking configuration at the end of the lab

NOTE: If you already started the install and missed the Execute Script part, or if later you notice that it did not get AD installed, see the appendix for instructions for using PowerShell from within DC01 to add and configure Active Directory.

Explore the virtual machines and connect via RDP

Now that the virtual machine is created, you want to log on and verify that it looks, feels, and behaves just like any server on your network.

Perform the following tasks in the Azure management portal:

On the left menu of the Azure management portal, scroll to and click VIRTUAL MACHINES.

To the right of DC01, click the DNS Name to open the Service dashboard.

Click the DASHBOARD tab.

You can review information about the running virtual machines, as well as view the current health.

Click the MONITOR tab.

You can view performance and data statistics.

Click the INSTANCES tab.

Note that DC01 is currently the only instance in this cloud service.

Click DC01 to open the virtual machine information.

Click the DASHBOARD tab.

You can review information about the virtual machines, as well as view the current health.

Click the MONITOR tab.

You can view performance and data statistics.

Click the ENDPOINTS tab.

You can configure published endpoints, which are similar to firewall rules, to allow applications to access services running on the VM.

Click the CONFIGURE tab.

You can modify the properties of the virtual machine. You can also configure monitoring from multiple locations to ensure your endpoint is operational.

Click the DASHBOARD tab.

On the bar at the bottom, click CONNECT, and then click Open.

Click Connect.

When prompted, log on as sysadmin using Passw0rd! as the password. (Substitute the username and password you used during VM Creation if different than the lab recommendations.)

Note: If you have trouble connecting as sysadmin, try sysadmin@ContosoAzure.com.

Click Yes.

You are now logged on to your newly created virtual machine.

Click No when prompted to enable discovery of devices.

Migrate DC01 to the designated static IP subnet

Your DC01 is currently assigned to the AD-Production-Static subnet. But this doesn’t actually assign it a static address that might not someday change. In this task, you will configure a static IP address using the new Azure Preview Portal.

You could accomplish what we’re about to do in two separate ways – the new Azure Preview Portal, or through PowerShell. For our Lab, we’re going to use the new portal, and then show you how it could be done using PowerShell.

While the new portal offers some great enhancements to managing Azure. It is still in preview, and this task will give you a glimpse into the new portal.

In the Azure management portal, click on your Account IDe-mailaddress in the upper right hand corner and click on Switch to new portal. Notice a new tab automatically opens

If prompted for your credentials, enter your ID and password to enter the new portal

On the left hand toolbar in the portal click Browse and scroll to and select Virtual machines

In the Virtual machine list select DC01

In the DC01 journey pane select SETTINGS

In the SETTINGS options select IP addresses

In the IP addresses journey, note that the Private IP address is set to Dynamic. Select Static.

Your IP address is probably something like 192.168.11.4, which is the first available address in our AD-Production-Static subnet. Change this to 192.168.11.100

Save up above.

You may now close the new preview portal tab.

DC01 designated static IP – Using PowerShell

NOTE: This is just informational! If you’ve used the new portal to assign the static IP address, you don’t need to do these PowerShell steps!

If you were to do this using PowerShell, you will need to make sure you have installed the Microsoft Azure PowerShell cmdlets and connect it (or authenticate) to your subscription. You can read the Install PowerShell Toolsappendix section for more information.

Open Azure PowerShell.

To test the pending static IP for availability, type the following command (on one line), and then press ENTER.

Test-AzureStaticVNetIP –VnetName ITC-VNet –IPAddress 192.168.11.100

The output of True indicates this address is available. An output of false indicates the address is assigned, and will also provide a list of available IP addresses.

To migrate the VM, type the following command (all on one line) and then press ENTER. Replace <ID> with your unique ID.

To verify the VM has been configured, type the following command, and then press ENTER. Replace <ID> with your unique ID.

Get-AzureVM -Name DC01 –ServiceName itcservice<ID>

Note the value of IPAddress and PowerState. The VM should have the assigned static IP on your new subnet, and be starting.

Before proceeding to the next step you may need to wait for the last operation to complete. Assigning a new IP address forces the VM to restart.

Create a new database server VM from the Microsoft Azure management portal

In this task, you will create the database server to run the database portion of our application. This will be a SQL Server Enterprise 2014 virtual machine. You will leverage one of the many virtual machine images that are located in the virtual machine gallery. Images are used in Azure to provide a new virtual machine with an operating system. An image might also have one or more data disks. Images are available from several sources:

Azure offers a gallery of images -- recent versions of Windows Server and several distributions of the Linux operating system. Some images also contain applications, such as SQL Server. MSDN Benefit and MSDN Pay-as-You-Go subscribers have access to additional images.

The open source community offers images through VM Depot.

You can store your own images in Azure, by either capturing an existing Azure virtual machine for use as an image or uploading an image.

Perform the following tasks in the non-preview Azure management portal.

Click NEW (“+”), located at the bottom of the Azure management portal.

Click COMPUTE, click VIRTUAL MACHINE, and then click FROM GALLERY.

In Choose an Image, click SQL Server, and find and select SQL Server 2014 RTM Enterprise. Click the Next arrow.

Create a new virtual machine using the values in the following table, and then click the Next arrow.

The virtual machine will take a several minutes to create. Depending on the load this may take between 15 and 35 minutes.

You will return to complete the rest of the SQL configuration in an up-coming lab.

Assign a new DNS server and subnet for the virtual network

In this task you will create a new DNS server entry. This entry will be assigned to all computers using DHCP on their next restart, since all VMs use DHCP in Azure, even the ones with “static IPs” as these are technically just DHCP reservations on the virtual network. Azure provides automatic routing between subnets on the same virtual network, but automatic name resolution only when machines are in the same Cloud Service. Though we won’t be doing so in these labs, if we were to add new VMs to the domain, they would have entries in DNS, so that it wouldn’t matter what cloud service they were in. They’d have name resolution through DNS on the Domain Controller.

URGENT NOTE: Please confirm that the creation of the domain is complete on DC01 BEFORE changing DNS. You can do this by looking in Server Manger on DC01. AD DS and DNS should both be listed in the left NAV. If you do not, name resolution will fail

Perform the following tasks in the non-preview Azure management portal.

In the Azure management portal, click NETWORKS.

Click ITC-VNet

Click CONFIGURE.

In dns servers, type DC01, and then in IP ADDRESS, type 192.168.11.100.

In this first lab you will create the core building blocks for your Azure services:

Virtual Network

Storage

Cloud Service

The services mentioned above are the core tenants that provide a foundation for your applications, virtual machines and hybrid connectivity in Azure. Having this well thought out provides a great architecture for all of your cloud services.

If this is your first time logging into your Azure management portal, close the WINDOWS AZURE TOUR.

Create a new virtual network and subnets for objects

First, you will create a Microsoft Azure network object and corresponding subnets. Azure Virtual Network lets you provision and manage networks in Azure and, optionally, link them via secured VPN tunnels with your on-premises IT infrastructure to create hybrid and cross-premises solutions. With virtual networks, IT administrators can control network topology, including configuration of DNS and IP address ranges. You can use a virtual network to:

Create a dedicated private cloud-only virtual network

Securely extend your data center

Enable hybrid cloud scenarios

With the virtual network you are creating will provide IP addresses assigned to objects and virtual machines you create in other labs that will be associated with this virtual network. You will also leverage subnets to help organize your IP addresses as well.

Perform the following tasks in the Azure management portal.

In the Azure management portal (in the leftmost column), scroll to and click NETWORKS.

Click NEW (Plus “+” Sign) located at the bottom left

Select CUSTOM CREATE.

In NAME, type ITC-VNet and then in LOCATION, select your closest location. Click the Next arrow.

Important: Remember this location choice. You will use the same location for all options in all labs

Leave all DNS setting blank, and then click the Next arrow.

his network will initially use Azure’s built-in DNS.

In STARTING IP, type 192.168.0.0.

In CIDR (ADDRESS COUNT), select /16.

Under SUBNETS, highlight Subnet-1, and then rename it to AD-Production.

Under STARTING IP, type 192.168.10.0.

Under CIDR (ADDRESS COUNT) select /24.

Under SUBNETS, click add subnet.

Name this second subnet AD-Production-Static.

Set the STARTING IP to 192.168.11.0.

Set the CIDR (ADDRESS COUNT) to /24.

Click the Complete icon (Check Mark at the lower right).

Create a new storage account from the Azure management portal

Microsoft Azure Storage is a massively scalable, highly available, and elastic cloud storage solution that empowers developers and IT professionals to build large-scale modern applications. Azure Storage is accessible from anywhere in the world, from any type of application, whether it’s running in the cloud, on the desktop, on an on-premises server, or on a mobile or tablet device. In this lab, you will create a storage account to contain all objects for your Azure services. Your VHDs, which you will create in lab 2 for your Azure virtual machines, will be stored in this storage account.

Perform the following tasks in the Azure management portal:

In the leftmost column, scroll to and click STORAGE.

Click NEW (“+”), located at the bottom of the Azure management portal.

Make sure STORAGE is highlighted and click QUICK CREATE

In URL, type itcstore<Unique ID (can use your initials)> For example: itcstoredan01Note: Your storage account name must be all lowercase

Create a new service from the Microsoft Azure management portal

By creating a cloud service, you can deploy a multi-tier application in Azure, defining multiple roles to distribute processing and allow flexible scaling of your application. A cloud service consists of one or more web roles and/or worker roles, each with its own application files and configuration. Azure Websites and Virtual Machines also enable web applications on Azure. The main advantage of cloud services is the ability to support more complex multi-tier architectures. In this section you will create a new service to contain your virtual machines. By assigning your new VMs to this service, they will be able to communicate internally.

On December 8, 2014 my friend Simon May and I recorded (while presenting live) a Microsoft Virtual Academy “Jumpstart” session all about how to manage iOS and Android devices with Microsoft solutions. We divided the topic up into 4 modules, to introduce the topic and the fundamentals, as well as to cover iOS and Android device management in greater depth. We covered how Microsoft products and solutions such as Windows Server, Azure Active Directory, Microsoft Intune and System Center Configuration Manager can be used to grant secured, managed access to corporate resources for those users who “BYOD”; their iPhones, iPads, or Android devices.

Ugh.. I was in the 2nd week of a pretty annoying chest cold. I hope the editors were able to edit out the random hacking and coughing. I felt fine otherwise. And <knock on Surface Type Cover> I and healthy now.

In this episode I am honored to welcome back Microsoft Vice President Brad Anderson to the show. We discuss his monthly upcoming live webcast series, “Success with Enterprise Mobility” , that kicks off on Tuesday, December 9th and concludes on March 3rd. Tune in as he gives us a preview of what he and his guests will be discussing and learn how you can successfully support business productivity for your users through secured and controlled mobility

.

[1:02] It’s been about a year since our last conversation on TechNet Radio. So what are you up to these days?

It isn’t a brand-new tool, but it was updated to version 1.1 the other day, and definitely worth sharing. The Microsoft Azure (IaaS) Cost Estimator Tool is now available. It’s an installable tool that allows you to “profile [your] existing on-premises infrastructure and estimate cost of running it on Azure.”

“Sweet! So, it installs agents on servers and then..”

Whoa! Lemme stop you right there! No agents. It’s agentless. It does require you to supply administrative credentials that will apply to the machines you’re profiling, which make sense.

The first time you run it, you’ll see this screen.

As you can see, the description of what it does and how it can be used are clearly spelled out.

And clicking Add, plus adding a couple of other machines (whose names might give away their purpose) results in this:

Clicking Next brings me to the page where I can choose a profiling duration, scanning frequency, and a name for the generated report.

I’m going to scan only one time, so my results won’t be based on more accurate, actual traffic or performance of my machines. But it’s good enough for a start.

I click Begin Profiling, and (in my case) after about 10-15 seconds my one-time scan is complete. I click View Report, and after an informational pop-up describing what was done and what options I have to change values, I see this screen:

Notice that I can tweak values and select just some or all of the machine before clicking Get Cost. I’ll just leave the values as determined, select all, and get my cost. Here is the result:

Notice that I can tweak the pricing model, and change the size of the Compute Instance (the type/size of VM) to play with various values. And when I’m done, I can export the results to a .CSV file (for use in Excel), or go back and try it all over again. Pretty nice?

“Very nice! But, what does this tool cost?”

Nothing. Nada. Zilch. Zero-dollar$.

“Sure. And I suppose once I run this tool I’m going to be bombarded with e-mails from Microsoft.”

Nope. Not even a requirement for a Microsoft Account to download, and no information is ever sent from this app back to Microsoft.

Seriously, Microsoft hopes that this will be a good way to get an idea of what your existing machines, whether physical or already virtualized, will cost to run over time as VMs hosted in our Azure Infrastructure Services. It’s all a part of helping you plan for an eventual migration of some of your local resources into Azure, to take advantage of the scale, capacity, security, and cost-benefits of the cloud.

Welcome to another in our series entitled “Modernizing Your Infrastructure with Hybrid Cloud”. As you may be aware, this week the theme is “Management and Automation”. As a part of that theme I’m sharing with you an introduction to Desired State Configuration (DSC); more completely called Windows PowerShell Desired State Configuration.

DSC is a relatively new (less-than-a-year-old) technology, introduced with PowerShell v4.0, that lets IT define what the configuration of a server will be, apply that configuration, and then verify (and remediate) so that the configuration is still in place and as-desired.

“So, it’s like System Center Configuration Manager?”

No. It’s built-in as a part of Windows, and is configured and implemented using PowerShell. Sound interesting?

“I’m listening.”

Good. In the context of one blog article naturally I won’t be able to go into every detail, but I hope that this article, some simple examples, and some additional resources at the end will get you excited for trying this out. And ultimately that you’ll see the immense value that this will give your IT and, of course, you’re business.

A Simple Example

For our quick example let’s assume a couple of things. I’ve enabled the Windows PowerShell DSC feature on a server named “Server1”. Server1 is a member server in my domain. I’ll be using an administrative account from another server (called Admin) to apply configuration to Server1.

I open up the PowerShell ISE and enter the following text. Can you tell what it’s doing from what the text says?

“It looks like it’s defining something that’s a ‘Configuration’ and calling it ‘IISWebsite’. And for your server named Server1, it’s laying out what Windows Features should be installed!”

Exactly! And in this PowerShell session, when I execute the configuration, I end up with a .MOF file, which is a definition on behalf of how Server1 should have the Web Server and ASP.NET 4.5 installed and running. All I need to do is run the Start-DSCConfiguration PowerShell cmdlet with the proper parameters referring to the .MOF file and pointing to Server1, and DSC configures the features and enforces that they always be there as I desired In fact, even if I or another administrator were to manually remove the ASP.NET 4.5 feature from the server, after a period of time the state would be re-evaluated and the configuration would be fixed!

What if, like those “WindowsFeature” sections, I were to add a “File” section like this:

Basically what I’m saying is, “Here’s the source folder of content that I want you to make sure is always found under this destination.” Ah.. and doesn’t the path look like it might be a web site folder? Yes! This configuration not only enforces that IIS be installed and running, but that the contents of a web application be always there and that the destination code always matches what is coming from the source! Someone could go in there and, say, delete some of the web content, but DSC would fix it automatically!

“Hey Kevin… What’s a .MOF file?”

Yeah.. this was a very quick, very simple example. Let me go through and briefly describe the parts that make up DSC…

The Parts – Configuration

The configuration is what we built in my earlier example. It’s a PowerShell definition that, using “Resources” (defined next) specify how things should be configured; our “desired state” for the configuration of a target server.

The Parts - Resources

In our example above, you notice that I’m defining what Windows Features are to be installed. I can do this because there is a built-in DSC “Resource” called “WindowsFeature”. From the TechNet Documentation, “Resources are building blocks that you can use to write a Windows PowerShell Desired State Configuration (DSC) script.” Windows comes with a number of these built-in resources that know how to specifically work with, configure, and enforce various aspects of the operating system. Resources for working with the registry, the file system, Windows Features, services… and many more, are included in the list of built-in DSC resources.

But it gets even better. These resources are just PowerShell modules. And just as you have the ability to create your own modules to extend PowerShell, you also have the ability to create your own custom resources!

The Parts - The .MOF file

This is the file that contains the configuration to be applied. It’s the result of executing the configuration definition in PowerShell, and is in a standard format as defined by the DTMF.

“Hey Kevin - Why do we even really need a .MOF file? Can’t Microsoft just do what it needs to do directly from PowerShell?”

I’m sure they could. But the beauty of using the .MOF is that because it’s a DTMF standard, it is formatted in a way can be applied to different machine types and for various purposes. In fact, at TechEd in Houston earlier this year I saw Jeffrey Snover actually use DSC to create a .MOF that then configured a Linux server running an Apache web server. (Yeah.. we’re “open” like that these days!)

The Parts - How It’s Deployed

The full name, “Windows PowerShell Desired State Configuration” is a hint about how you enable the DSC capability. It is a feature of Windows Server 2012 R2, found here in the Add Roles and FeaturesWizard:

When you check the box, you’ll notice that it will also install some Web components to your server…

This is because one of the ways DSC configurations are securely pulled is to use IIS.

The Parts - Push-me-Pull-You?

One important aspect of DSC is that it becomes even more powerful when you can distribute configurations, or maintain consistent configurations among many machines, all from a smaller number of source locations. DSC allows either a simple “push” distribution, which is simple and more manual, and a “pull” distribution where not only do you apply a configuration to a machine but you also tell it where it should be looking for its configuration and any changes going forward. Pulling can take place over HTTP (not recommended), HTTPS (recommended), or SMB Share permissions (okay because it’s authenticated access).

“Why isn’t HTTP recommended?”

Think about the damage someone could do if they hijacked DNS and then pointed to and automatically applied someone else’s version of a server configuration to your servers. Scary prospect, indeed.

The Parts – The Local Configuration Manager

The Local Configuration Manager is “the Windows PowerShell Desired State Configuration (DSC) engine. It runs on all target nodes, and it is responsible for calling the configuration resources that are included in a DSC configuration script.” So basically when you’ve enabled the DSC feature on a server, this is the service that either takes the pushed configuration, or pulls the configuration, and then applies it as defined in the most recent .MOF file.

For More Information…

Like many of you, I find that I learn best by looking at other people’s examples. And thankfully in the case of PowerShell and DSC there is a really big community already formed and willing to share what they have done with the rest of us. Here are some of the places I recommend you check out and save to your favorites if you’re really going to get serious about using Desired State Configuration:

I’m sure they won’t mind me sharing this.. but here is the text from an e-mail I received on the subject that spells it out nicely:

We are pleased to announce that System Center Data Protection Manager (DPM) is now supported to run in Azure as an IaaS virtual machine. This announcement allows customers to deploy DPM for protection of supported workloads running in a Azure IaaS virtual machines. Customers with a System Center license can now protect workloads in Azure. Read more about it on the DPM blog.

Support for multiple virtual machine sizes

Choose the size of the virtual machine instance that will run DPM, based on number of workloads and the total data size to be protected. Start with just an A2 size virtual machine, and upgrade to a larger size to scale up and protect more workloads.

Support for Microsoft Azure Backup

Protect your data to Microsoft Azure Backup and get longer retention with the flexibility of scaling storage and compute separately. The Microsoft Azure Backup agent works seamlessly with DPM running in an Azure IaaS virtual machine.

Familiar management using the DPM console

With DPM running in an Azure IaaS virtual machine, you get the same experiences and capabilities that you are familiar with.

In this article I’m going to show you step-by-step how to connect your Azure virtual network to your on-premises network. Here are the steps we’ll go through:

Collect Some Information

Define the “Local Network”

Enable Site-to-Site

Create the Gateway

Configure the Local VPN Device

And as an added bonus, I might throw in a little something extra.

“Sweet!”

I hope you’ll think so. But for starters, let’s begin where Matt left off. I have an Azure subscription with a virtual network named AzureNet1, located in the South Central US datacenter region. In my scenario, I want to connect this Azure network to my Fabrikam office (Fabrikam was recently purchased by Contoso). Once the connection is established, I will want to join servers in that office to the contoso.com domain.

Here’s what the AzureNet1 network dashboard tab currently looks like. Note the two virtual machines currently in this network; a domain controller and an application server.

As you can see on the configure tab, I’ve set up two subnet ranges (their purposes are obvious based on the names I’ve given them) as part of an 8-bit-masked 10.x.x.x subnet.:

Notice that I’ve also defined my DNS server as 10.0.0.4. My domain controller has that address.

Collect Some Information

Before we start adding the site-to-site connection, I need to collect some information so that I can carefully use it to make the correct configurations. As you probably know first-hand, when doing networking configuration it’s easy to make simple little mistakes that cause everything to NOT work, so let’s make quick note of a couple of important items:

Local Network Address Range

Gateway Address

Your local network address range refers to the addressing of your local network. By that name, though, it’s a little misleading. “Local” assumes you’re connecting your Azure network to some “Local” office. But in reality it could be some other branch office or even another virtual network somewhere else in the Azure world. So, just think of “local network” as being “the network I’m connecting to my Azure network”. And I’ll keep using “local network” in “quotes” throughout the rest of this article for just that reason.

The Gateway Address is the externally accessible IP address of the gateway. In the Fabrikam network, let’s say that I have a VPN device connected to the Internet with an external Internet-exposed address of 23.101.125.64. I will also have a gateway address on the AzureNet1 gateway, but that address will be assigned when I create the gateway for my virtual network. So, in simple terms, the gateway address is the connection point on either end of the VPN connection.

Define the “Local Network”

Before enabling the site-to-site connectivity and creating the gateway, we need to define the “local network” Fabrikam, so that our network knows what addresses it will be routing to over the VPN through the gateways.

To define my “local network” (which I’ll name “Fabrikam”), I clicked on +New in the bottom-left corner of the Azure portal, and selected Network Services –> Virtual Network –> Add Local Network.

I give my local network a name, an optionally the gateway address (I can add it later if I don’t know it right now.)

Then on the next screen I add the address spaces that exist at my “local network” at Fabrikam.

Once created, you’ll see it in the list on the local networks tab.

Enable Site-to-Site

Back on my AzureNet1 network and on the Configure tab, now I can check the box to enable Site-to-Site Connectivity. Notice that a couple of things change. I now will choose which “local network” I’m going to connect to (Fabrikam), and it also requires (and defines) a “Gateway Subnet” for me.

“Hey Kevin.. What’s that ‘ExpressRoute’ option?”

That’s actually what my friend Keith Mayer is going to cover in tomorrow’s article in the series. I’ll include the link to his article after it’s published.

Anyway, after checking Connect to the local network, clicking Save starts the process of updating the network configuration. After a couple of minutes it completes, and now back on the dashboard tab we see this:

This means the gateway is in defined, but not actually created. That’s our next step.

Create the Gateway

At the bottom of the dashboard screen, click on Create Gateway.

Notice when you click it that you are given a choice between a static and dynamic routing VPN gateway.

“What’s the difference?”

Your choice will be based on a number of factors. Often the VPN hardware you are using will limit you to one or the other. A staticrouting VPN gateway is one that routes traffic based on policy definitions (which is why it’s often referred to as a Policy-based VPN). Packets are routed through the gateway based on a defined policy; an “access list”. A dynamicrouting VPN gateway, also known as a “route-based VPN”, is a simple forwarding of packets between two networks. If the network doesn’t locally contain the destination for this packet, I’ll assume the gateway knows where to send it. And if it’s known by the gateway as existing on the other network, it sends it securely through the tunnel. For more information about these choices, and about various devices and gateway types that support either static or dynamic VPN gateways, check out this excellent documentation. Even if your device is not on that list, it may still work if your hardware supports

In my scenario I’m creating a simple tunnel to a device that supports the other end of dynamically routed VPN, so I’ll choose Dynamic Routing. Creating the gateway does take a good amount of time (as much as 15 minutes), so be patient. Eventually our display will go from this:

…to this:

…and eventually, this:

Notice that we’ve been assigned an official actual external gateway IP address. We’re still not actually connected. (Connected would be GREEN in color.) We haven’t addressed the configuration of the “local network” side of our connection yet. At the bottom of the page you see a Connect button:

But let’s not click that just yet. We still need to…

Configure the Local VPN Device

Other than collecting some information about our Fabrikam network, we’ve only focused on the AzureNet1 side of our VPN tunnel. We still need to create the gateway on our Fabrikam network.

On the AzureNet1 dashboard, notice this hyper-link towards the right-side of the page:

Clicking on Download VPN Device Script this brings up a very interesting page that allows us to specify what kind of hardware (or software) we have on the “local network” side of our connection. The beauty of this is that, based on our selection of hardware (or even Windows Server 2012 and 2012 R2 Routing-and-Remote-Access (RRAS) working as your gateway), you are generating a script that can then be used to automatically configure your gateway on the “local network” side.

Use this script to configure your device, establish the connection from the local network, and then come back to the Azure network dashboard and click connect. And if you’ve done everything correctly, you should see something happy (and GREEN) like this:

“What kind of hardware do you have on Fabrikam’s network, Kevin?”

I don’t know. I’m not actually using a local network. For this demonstration, I’ve actually connected my AzureNet1 network, which is located in the South Central US datacenter region to a Fabrikam virtual network that host in the Central US datacenter region and manage through an entirely different Azure subscription. So.. I’m doing Site-to-Site between two Azure virtual networks. That’s my “something extra” that I promised earlier. Now I’m going to show you what I needed to do to make that connection work.

I’ve already showed you where you choose Dynamic Routing when you create the gateway. And other than the shared key, everything else I did for configuring the Fabrikam network was identical to what I configured in AzureNet1, except that my network in Fabrikam is 192.168.0.0/16 – identical to what I defined the “Fabrikam” “local network” to be on this side. IMPORTANT: These have to match. The range and mask have to be correct and consistent on both ends both the “local network’' definition and the actual network (or Azure virtual network as in my case) for this to work.

Also in the definition of the “local network” on either side was the specification of the Gateway IP Address. Again, ordinarily, your configuration script is populated with the Azure virtual gateway’s IP address. But in this instance, I need to create the gateway first, and let it fail connecting, just so I can see what the actual assigned gateway IP address on that side of the connection is going to be. Then I can take that address and configure it into the “local network” definition on the other side.

As for the shared private key.. Notice at the bottom of the AzureNet1dashboard that there is a Manage Key button:

If I click this, I can see (and copy) the generated long key. I’ll copy it to the clipboard.

This key was created when we created the gateway, and is included for you in the configuration script on behalf of your “local network” device. But…

“We don’t have a local network device!”

Bingo. And we also don’t (as of this writing) have a way to use the Azure portal to set the shared key in and the configuration of the virtual network! But we will need to do that to at least one end of the tunnel to make sure they match. (Or both if we want to just use our own text as the shared key.)

This is where PowerShell comes in.

I’ve installed the Azure PowerShell cmdlets onto my local system, and then in PowerShell I connected to my Azure subscription where the Fabrikam virtual network resides. And now I use the following PowerShell command to set the shared key for the gateway connected the Azure network Fabrikam to the (from this point of view) “local network” named AzureNet1.

(For the Windows PowerShell command-line tools, go to the Azure downloads page, and scroll down to “Windows PowerShell” section. Instructions for setting this up are found there as well.)

That’s how I was able to get the common shared key into the other side of my connection. After this command completes, and soon after clicking Connect in the dashboard, I was happily sending data back and forth.

---

“But Kevin… Prove to us that you have the connection established! Finish your domain-joining scenario!”

Right!

In the AzureNet1 network I have two servers. One is a domain controller, and the other is a member server. All machines here are assigned their DNS server as 10.0.0.4. They reside in the South Central US datacenter region.

On my Fabrikam network (which, you’ll recall remember, resides in the Central US datacenter region, so not in the same location as the AzureNet1 network and machines) I have one server that I’ve just created:

Importantly, I’ve also created a “DNS Server” designation here, and assigned to the Fabrikam network, with the 10.0.0.4 address. Note the configure tab of the Fabrikam network.

In this way my machines in this Fabrikam network will be assigned 10.0.0.4 as their DNS server, and so will know how to find the DC in the AzureNet1 network. To verify this I can establish a remote desktop connection to my new karContosoDC2 server and look at the status of the network adapter:

Trusting that my VPN is happily and dynamically routing traffic between Fabrikam and AzureNet1, and knowing that my new server in Fabrikam is going to look for DNS at the domain controller in AzureNet1, I attempt to join the domain:

I am asked for domain credentials (a very good sign!)…

And..

I’m in! That’s proof that I have successfully connected these two virtual networks!

Keith Mayer and I continue our series on “Modernizing Your Infrastructure with Hybrid Cloud”. In today’s episode we discuss various options for networking. Tune in as we go in depth on what options are available for hybrid cloud networking as we explore network connectivity and address concerns about speed, reliability and security.

Welcome to another in our new series of “Modernize your Infrastructure” articles. Today I’m pleased to share with you the details of yet another free and easy-to-use assessment tool from Microsoft. The purpose of this tool is to help you answer the following important question:

And that is a fair question; particularly if we see the value, but don’t really know where to begin. If in the process of modernizing my infrastructure I consider perhaps moving some (or all) of my servers – whether they’re physical or virtual machines - off of my local hardware and into “the Cloud” as Microsoft Azure hosted Virtual Machines as an extension of my datacenter, then it would be good to have a starting-point assessment to help me learn about and consider what might be required; and even better if it was based on my current environment and some initial goals and desires.

It’s a free and easy-to-install tool that, when run on supporting OS and with the proper credentials, will ask you a number of questions about your environment and about your needs and desires (the end goal), and result in a lengthy report based on your answers and, importantly, based on what it was able to detect in your infrastructure.

“Can you show it to me?”

Showing you the whole process would be overkill here. But how about I show you some of the highlights.

“Okay.”

Requirements and Installation

The download page is where you’ll find a good description of how and where the tool can be run. In basic terms, it will run on any OS newer than Windows Vista and Windows Server 2008. It does have some .NET framework requirements as well. The instructions are pretty simple:

1. Download and run WAVMRA.EXE on the computer you want to run the assessment from2. Complete the installation steps3. Launch the tool4. Select the technology you want to assess and proceed through the wizard experience

Run it

On the workstation you’ve installed the tool on, make sure you run it as an administrative account that has rights to administer Active Directory, SharePoint, or your SQL Servers (whatever it is you’re interested in assessing).

Naturally, the first question you are asked is “What would you like to assess?”

Your answer here will determine some of the remaining questions concerning what kind of connectivity, applications, availability, and performance you’re going to require.

Let’s say that In my example I’m going to want to extend my Active Directory domain into the cloud. Using my single corporate domain I want to extend authentication to other applications that I want to host on virtual machines in my Microsoft Azure network.

Prior to the remainder of the questionnaire, you are reminded of the requirements for this tool to be able to run successfully:

Answer the Questions

The rest of the process prior to scanning your environment and generating the final report, is to ask you additional questions. In my scenario, I’m asked 13 more questions. “All questions must be answered as part of completing this assessment.” Here are a few samples:

Note that each question provides additional detail about what’s being asked, and you are often giving the option to basically say “I don’t know yet”. Trust me – The report will give you excellent detail on and pointers to additional information about all of the options available.

And eventually…

YOUR REPORT

The tool generates a Microsoft Word .docx file that you can save, print, share.. whatever you want to do with it. Inside you’ll find a detailed report on what you’ve chosen, what’s required of you, and links to additional information and further learning around your next steps. The report is organized into three parts: “Ready”, “Set”, and “Move”.

And then shows you “What we checked”, with a quick visual indication of which items are fine, and which ones should probably be looked into further.

And that’s it!

Hopefully you’ll find this a useful first-step into extending your infrastructure into the Microsoft Azure cloud.

The team of US DX IT Pro Technology Evangelists is doing another series of articles and TechNet Radio interviews. The topic: Modernizing your Infrastructure. The goal: To give you as many resources as you’ll need to get your infrastructure up to speed, whether you’re simply looking for ways to migrate off of Windows Server 2003, or even move workloads and applications up into Microsoft Azure.