1.  Create Azure Resource Group
   1. In the Azure Portal, Click on Resource Groups.  Then Click Add.
   2. Fill-In "Resource Group Name", Choose Your Subscription, Select Location, and Click Create.
2. Create Virtual Network
   1. In the Azure Portal, Click on Virtual Networks.  Then Click Add.
   2. Fill-In Fields:
      1. Name: My-Virtual-LAN
      2. Address Space: 172.10.0.0 / 16 (255.255.0.0)
      3. Subnet Name: Backend
      4. Subnet Address Range: 172.10.1.0 / 24 (255.255.255.0)
      5. Resource Group: Use Existing > My-Resource-Group
      6. Location: (Same Location as Resource Group)
   3. Now Create the Subnets:
      1. Click on the New Virtual Network You Just Created.
      2. Now Click "Subnets" on the left side.
      3. Now on the right, click the "+ Gateway Subnet".
      4. Fill-In:
         1. Name: GatewaySubnet
         2. Address Range: 172.10.0.0 / 24 (255.255.255.0)
      5. Click Create.
3. Create Virtual Network Gateway
   1. In the Azure Portal, Click on Virtual Network Gateway.  Then Click Add.
   2. Now Click Add.
   3. Fill-In Fields:
      1. Name: My-Virtual-Gateway
      2. Virtual Network: Will Be Network You Created in Previous Step.
      3. Public IP Address: Choose from list or Click Add IP.
      4. Gateway Type: VPN
      5. VPN Type: Route-Based
      6. Location: Same as Above.
      7. Click Create.  (May take a little while to finish.)
4. Create Local Network Gateway
   1. In the Azure Portal, Click on Local Network Gateway.  Then Click Add.
   2. Fill-In Fields:
      1. Name: My-Local-Network-Gateway
      2. IP Address: Public IP of Your Home/Lab
      3. Address Space: 192.168.1.0 / 24 (255.255.255.0) (Your Home Network)
      4. Resource Group: Resource Group Created Earlier
      5. Location: Same Location
      6. Click Create.
5. Create VPN Connection
   1. In Azure Portal, Click on your Local Network Gateway (My-Local-Network-Gateway)
   2. Click on Connections.
   3. Click Add.
   4. Fill-In Field:
      1. You will need to specify the Virtual and Local LAN gateways we created in Step 3 and Step 4, for the Virtual Network Gateway and Local Network Gateway, respectively.
      2. Shared Key: Using a random 32-bit key is important.  This can easily be generated with something like powershell or like this tool.  Generate a 32-bin key and put it in the Shared Key PSK field.  Also keep the key because you will need it later in this tutorial.
      3. Click Create.
6. This completes the Azure Configuration. Next Begin RRAS Configuration.
7. On any windows machine on your home/lab network, install the RRAS Role.
   1. Powershell: Install-windowsfeature -name directaccess-vpn -IncludeManagementTools
8. Configure RRAS:
9. The Routing and Remote Access Server Setup Wizard will appear.
   1. Welcome to the Routing and Remote Access Server Setup Wizard: Click Next
   2. Configuration: Select Secure connection between two private networks, click Next
   3. Demand-Dial Connections: Select Yes, click Next
   4. IP Address Assignment: Select Automatically, click Next
   5. Completing the Routing and Remote Access Server Setup Wizard: Click Finish
   The Demand-Dial Interface Wizard will appear.
   1. Welcome to the Demand-Dial Interface Wizard: Click Next
   2. Interface Name: Type in Azure S2S, click Next
   3. Connection Type: Select Connect using virtual private network (VPN), click Next
   4. VPN Type: Select IKEv2, click Next
   5. Destination Address: Enter in the Public IP address of the Azure Virtual Network Gateway, click Next
   6. Protocols and Security: Check Route IP packets on this interface, click Next
   7. Static Routes for Remote Networks: Click Add
      • Static Route: Select Remote Network Support using IPv4:
        • Destination: 172.10.1.0
        • Network Mask: 255.255.255.0
        • Metric: 1
        • Click OK
      • Click Next
   8. Dial-Out Credentials: Type Azure for the User name, click Next
   9. Completing the Demand-Dial Interface Wizard: Click Finish
   In the Routing and Remote Access window select RRAS-Server -> Network Interfaces.  Right-click on Azure S2S and select Properties. Select the Security tab and under Authentication select Use preshared key for authentication. Type in the preshared key that was entered on the VPN Connection in Azure.  Click OK. Right-click on the Azure S2S network interface and click Connect. After it connects open up a command prompt and ping any IP on any VM in your new Azure Network 172.10.1.x.  You should get a response. Now any Azure VM that you put on 172.10.1.x will be able to communicate directly with your on-premise systems. In order for any on-premise systems to communicate with the Azure VMs you will need to setup a static route on your home router.  In this configuration, I created a static route on my router configured like this:
   1. Network: 172.10.0.0
   2. Netmask: 255.255.0.0
   3. Gateway: 192.168.1.202 (Internal IP of your RRAS Server)
   4. Metric: 1

The issue that was occurring was that when any user was moved from the old pool to any of the pool's on the new R2 environment, that user would not be able to communicate with any user still in the old pool.  Needless to say, this was a major problem for the migration.  After some research, we were able to nail it down to an "old server" to "new server" communication problem.  The communicator client worked no matter which server you pointed to or which pool your account was in.  This further enforced server-to-server communication to us.  Here is some error information that we were getting:

With some research and consultation,

 we found that there were some patches that could have an impact, so we gave them a try.  After installing hotfixes KB957465 KB956389 on the old server and the communicator client, we rebooted the old server and the server-to-server communication began working immediately.  These patches and the reboot resolved the issue for us.  Once that was working, we noticed that no more than 2 people could join a session on the new pool's.  A few minutes of research later, and we found that KB974009 fixed the issue. 

So if you are having communication problems while doing an OCS migration, those hotfixes/procedures may help you.

 So today I am going to do something very basic and simple.  I am going to show some sample vbscript code that will read a specified directory and display out the names of all files inside of that directory.  This is the very simple beginner script, so it does not do things like recurse subdirectories or account for things like the directory you specify being missing.  Those are more complex and I will post some of those things in the future.

 So to start off, I have made the script to allow you to feed it the directory to search, rather than hard-coding it into the code.

To run the above code successfully, I would run it in a command prompt with something like this:

c:>cscript script-name.vbs c:temp

In that example, the script would scan "c:temp" and report back the files it find in that directory.  Yes, running "dir c:temp" from any command prompt would accomplish similar results, but by doing it in vbscript it opens up all sorts of possibilites.  Once I identify each file, I could provide a lot more data about each file and I could then perform other actions on them as I needed.  Again, I will cover some of that later.

In contrast, to do a similar task in powershell, it would be:

 That code would do basically the same as a "dir" at a command prompt whereas the vbscript would ONLY list the files in the directory and not subdirectory.  To make the above powershell recurse all the subdirectories, simply add "-R" to the command.

I hope to be able to post far more useful and complex scripts as time allows.  I will also try to point out the differences between the scripting techniques, like vbscript or powershell, as I walk through them.

 As I begin this very first Blog post, I had thought about writing about many different topics.  I had considered starting with a simply technical post with maybe some script code or a technical thought.  Instead, I decided to write about something that I have been experiencing onsite with my customer and starting from that point to see where it leads.  So I decided on the topic or question of "What makes an IT project successful?".

 There are many factors that come into play in an IT Project.  Some would say that a project manager or a quality engineer make it work while others would say that a good support person or a project sponsor are the key elements to success.  In most cases, I could not argue that all of those things and many more are very important to have and arguably the most important.  However, I have a slightly different view on the situation.  I think the single most important thing to making an IT project a success is something that can be said for many things outside of IT.  I think that its one of the simplest things that we rely on yet overlook constantly.  I think the single most important thing to being successful is Relationships.  Yes I think relationships can make or break an IT project just like it can make or break many other things as well.

 If you sit back and think, you could have a room full of top quality engineers, program managers, support personnel, a passionate project sponsor, a CIO with a very healthy budget, and yet still have a failing project.  With all the right pieces, how could a project fail?  Well in my experience, without the right relationships in place, it will fail.  You could have all of these key people and resources, but if they cannot communicate and have a productive working relationship then the project will fail.  I have seen it happen time and time again.  I have fortunately been able to resolve many situations and help get projects back on track even when I had little or no involvement in the project just because I was able to get different people to communicate or be a "bridge" between different people.  Communication and relationships are truly what makes things happen.  If your storage tech cannot effectively communicate with your PM or your backup tech, then you have a problem.  If your engineers do not have a relationship with your implementation or O&M people, then you have problem.  The examples could go on for days.  Although it seems so obvious and simple, it is so overlooked on so many IT Projects.  Its often an easy thing to fix once the problem is identified and admitted by the people involved.  Unfortunately it sometimes either comes too late or at the loss of millions of dollars due to lack of productivity.  When relationships are not present, everyone loses. 

 So, if you find yourself working on a struggling project and want to do something to make it work, consider what relationships or communication lanes that may not be open in the project and what impact they have.  Although it can sometimes be a struggle, getting people to put down their defenses and just talk sometimes resolves the majority of the problems.

 So simple, yet so often overlooked.