Category: Networking

Deploy VPN connection remotely

Jeff Miles Leave a comment

Here’s what I’ve developed to push a VPN client connection within Windows networking to remote PCs. One flaw is that this is user-based; I’m not sure if it could be applied to all users.

  1. Create a VPN connection with your desired settings on a template workstation
  2. Navigate to %appdata%\Microsoft\Network\Connections\Pbk
  3. Copy “rasphone.pbk” to a central source
  4. Either distribute that .pbk file directly to users to double-click on, or drop it into the same folder on their profile as it was originally retrieved from.

This .pbk file doesn’t store user credentials, so you will need to inform your user of those in advance.

Hyper-V NIC Team Networking issue

Jeff Miles Leave a comment

I encountered an issue with a Hyper-V virtual machine recently that had me very confused. I still don’t have a great resolution to it but at least a functional workaround.

At a site I have a Server 2012 R2 Hyper-V host (Host), a Server 2012 R2 file server guest (FileServer) and a Server 2012 R2 domain controller (DC).

The Host has two NICs in a single switch-independent address hash team. This Team is set as the source of the vSwitch which has management capabilities enabled. We wanted to use a NIC team to provide network redundancy in case a cable was disconnected as this network is being provided by the site owner rather than my company.

Host and FileServer could reach DC, but nothing else could. DC could reach Host and FileServer, but not even it’s own default gateway.

This immediately sounded like a mis-configured virtual switch on Host, as it appeared DC could only access internal traffic. But I confirmed the vswitch was set to “External” and if this were the case the FileServer would have presumably been affected by this issue as well, but it was not.

I tried disabling VMQ on the Host NICs, as well as Large Send Offload, since both those features have been known to cause problems, but that did not resolve the issue either.

I tried changing the teaming algorithm to Hyper-V Port and Dynamic, but that didn’t resolve the issue either.

Then I decided to put one of the NICs into a Standby state in the team. This caused the accessibility to switch between the VMs; all of a sudden nothing external could reach my file server, but the DC came online to external traffic.

I tried changing which NIC was in standby but that still left me with one VM that had no connectivity.

My assumption at this point is that this issue is being caused by Port Security on the network switches; something that we are aware the site owner is doing. I suppose that the Team presents a single MAC address across multiple ports, which the port security doesn’t like and so it blocks traffic from one side of that team. Because of how traffic is balanced across the team it leaves one of the VMs in an inaccessible state.

Unfortunately we do not have control over this network or the ability to implement LACP, and so I’ve had to remove the NIC teaming and go back to segregated NICs for management and VM access.

 

File Server and remote office collaboration

Jeff Miles 2 Comments

I had someone email me about DFSR and file locking based on some old comments on a Ned Pyle post from the Ask DS blog on technet.
I wrote up a detailed response of how I’ve handled this issue in my environment, and decided that response would make a good post to share, so here it is:

 

It’s a long story actually. Not sure if you read my post from April 2013, but I effectively gave up on DFSR due to the instability we were experiencing. Still not sure if it was underlying storage causing it, or just the scale at which we were operating. PeerSync couldn’t keep up with the rate of change on our file servers when we piloted it, and neither could PeerLock when we tried to integrate it with DFSR.

So stuff crashed in April 2013, I gave up on DFSR and we intended on using Silver Peak WAN acceleration across our site-to-site VPNs, combined with RDS or Citrix XenApp.

Then my company was acquired by a much bigger engineering firm, and all my plans were interrupted. We basically left our users to suffer (since we had already used DFSR to create a single namespace, when we quit DFSR we just kept a ‘single source of truth’) for months because the parent company was going to roll out a global WAN.

That did eventually happen in late 2014, so at that point we had Riverbed Steelheads providing 80% data reduction across the WAN and a 7ms link between our biggest branch and head office (where the most pain was for ACAD production).

We occasionally heard rumbling from staff that it wasn’t good enough, and so we pressed on-wards with purchase of a 30-seat Citrix XenApp environment with a dedicated nVidia GRID K2 card for GPU acceleration. However we really screwed up the user communication and training and failed to get adequate buy-in from CAD management to enforce it’s use.

XenApp works fantastic for apps like ArcGIS Desktop and GlobalMapper, but

we really struggled with mouse lag in all AutoCAD streams (except Revit which we don’t use). We went as far as a specialized consultant out of the UK and they couldn’t figure it out either.

I had begun the process of looking at Panzura, which I raved about here. It still looks like the best overall solution to a centralized file server with geographic collaboration on AutoCAD files. But the price tag for two offices was close to $60k not counting cloud storage costs, and I had just purchased a whole bunch of new storage so i didn’t want new Panzura hardware, and they don’t support Hyper-V for their virtual instance (which still blows my mind).

Ultimately, a couple months ago we had a big meeting with all our CAD managers and consensus was that:
– The majority of work performed in branch offices is acceptable due to the Riverbed Steelheads and low latency provided by the global WAN
– The work that doesn’t perform well due to huge file sizes would be done with XenApp and the mouse lag would just be accepted. But I don’t think the CAD managers are actively encouraging this.

And that’s where we’re at right now; not really solving the issue but trying to find improvements as best we can.

Benefits of networking – and Panzura

Jeff Miles 2 Comments

The concept of networking is very often mentioned within IT, but examples of it do not come up nearly as often in my experience.
However recently I do have such an example. A colleague attended Autodesk University in late 2014, and attended a session regarding file collaboration for products like Autodesk Revit and AutoCAD.
This is an area which I have been struggling with for many years. How does one give LAN-like speed to a single set of data across many geographical locations? I’ve tried many solutions as posted about previously: DFSR, PeerLock, PeerSync, GlobalScape WAFS, Citrix XenApp and others.

And yet all of these have not proven effective enough to permanently rely upon.

But at Autodesk University the session was talking about Panzura. A representative of a company almost exactly like mine was talking about the benefits, and how it has solved the file collaboration problem for them.

When this news was returned I became very excited, and eventually came across this testimonial video: this video is even more evidence that this might be the right path to travel down.

I was put in direct contact with this representative and can now communicate without sales over-exaggerating the benefits of the product.

 

There is still a large amount of research and testing ahead before Panzura can be seriously considered in my environment, however it is something I would not have seriously considered without the networking.

HP MSM AP Static Provisioning

Jeff Miles Leave a comment

I’m currently setting up a controlled WiFi network to adhere to my parent company’s standards. We’re using the HP MSM760 controller with MSM460 access points.

I had everything set up and tested within my head office environment, however I ran into an issue when I moved the AP’s to a branch office on a different subnet.

Every AP that I moved registered with the MSM controller in Australia rather than Canada where I am. After some reading of the manual I determined it did this because the discovery of the controller works in this order:

  • UPD broadcast
  • DHCP options
  • DNS lookup (to cnsrv1)

Because the Australian controller predates mine, they had already set up and used the DNS name “cnsrv1”. Since my APs no longer detected a controller through the UDP broadcast because of the new subnet, it resolved the DNS name and re-registered.

 

To move my APs back to my controller I had to do the following:

From the Australian controller, change the AP to Autonomous mode:

switch_to_autonomous

 

Then I checked my DHCP server for the current IP of the AP, because it changed after switching to autonomous mode

Following that, I logged onto the web interface of the AP.

Then I used Maintenance > System > Provision to enter the static provisioning settings:

provision

I enabled discovery, enabled discovery by IP, and entered my Canada controller IP and clicked save:

provision2

Then from the left side of the screen, clicked Restart to confirm the static provision:

provision3

When the AP came back up, it registered on my Canada controller and all is good!