Moving server to Rackspace - AD & DHCP questions

[porterj5]

We are attempting to move our in house server to a hosted on with Rackspace. We are currently running Windows server 2003 which is managing active directory, dhcp, network storage for all client files, and a couple of tax programs. They gave us an awesome price that includes offsite back ups and managing the server maintenance that we were going to have to be paying someone to do anyway if we kept it in house.

 

I had talked to them and they said that it would be no problem to move the active directory to a 2012 server hosted by them.  We have a site to site VPN set up and my understanding is that it will show up as just another computer on the network. In talking to the tech guy who installed our new firewall he made a comment about possibly some complications with active directory and dhcp.  He said the firewall could host the dhcp but there was a lot of set up to change things.

 

Would it be possible to host the active directory on the hosted server and dhcp on the firewall?

 

Are there any other possible issues with having the server offsite?

[The Benjamins]

What is the server being used for, if a lot of file transfer stuff is needed a off site solution might require you to have a very good internet connection.

[Falconevo]

Sounds like you have spoken to a 'technical pre-sales' who fail to tell you all the problems that come with this type of thing.

 

Here are some tips off the top of my head from me as I work specifically in this industry and have done a fair number of these 'migrations'.

 

1. Have a domain controller on site at all times in the event the site to site VPN is down you will have no one able to login.  This will happen, on the day it does you will read this post again and wonder why you didn't.  Do not rely on site to site VPN's to be online all the time, things happen that are outside of your control.

 

2. Keep DHCP onsite, do NOT move DHCP externally over a VPN, that is absolutely fucking ludicrous and anyone promoting it should be kicked in the face.

 

3. Set primary DNS of all machines in the office to the local domain controller and the secondary DNS to the DC in the hosting provider

 

4. Adding a 2012 DC to a 2003 domain is fine, however its functional level will stay at the lower 2003 mode until the 2003 domain controller is decommissioned and FSMO roles move to the 2012 DC as primary then domain functional level upgraded.  I would NEVER recommend having just a single domain controller, EVER.

 

5. Even with a 'managed' service you will still be completely responsible for your user accounts, group policies and permissions.  Any sales person telling you otherwise is full of it.

 

If it was me I would look at 'Desktop as a service' DaaS instead as it would probably be a better alternative for you which is actually managed.

[porterj5]

@Falconevo, thank you for your reply.  We signed up for it and have a 30 days get out of the contract free guarantee.  During this time I have been talking with their tech support team for Windows server and network support trying to get the site to site VPN set up (turned out our ancient firewall was not up to the task so we finally replaced it).  They also said that this set up should work.

 

We have a 60 down 5 up connect at our current office and should be moving in the next couple weeks to an office with 100 down and 10 up.  We access a lot of QuickBooks files from clients from the server and access the data for our tax software from it.  We have about 500GB of data that we regularly access.

 

We were attempting a hosted solution so that we would not have to have an on site server to maintain. If having this type of hosted solution has the pitfalls you listed without having an onsite one then I think we are back to looking for in office hardware.

[Falconevo]

@porterj5

Your upstream is unsuitable for this type of remote functionality, anyone attempting to make changes/upload content to a remote file share will see it crawl like a snail even with the updated 10Mbit/s upstream.  A minimum for this would be 30Mbit/s upstream if you can get an ISP with that availability, this is going off my own experiences.

 

If you move things offsite, you generally need a suitable internet service to make the best of it.  Slowing things down for end users just brings general day to day tasks take longer, users get frustrated and productivity takes a turn for the worse.  Bare in mind that the site-to-site VPN adds overhead to the connection and drops the MTU so it becomes even slower than the 5 or 10Mbit upstream from the ISP.

 

You will still need services in house, DHCP can be handled by the firewall but will need someone to configure the DHCP range(s).  A domain controller will need to be kept in the offices to allow for local logon should the site-to-site VPN be down.

 

With Rackspaces proposal you are basically placing all of your business functionality on a site-to-site VPN with absolutely no redundancy, this in my opinion is far too risky but I'm not the business owner.  I can assure you the management of active directory infrastructure, users, permissions and security will be left to you unless you pay £££ for every support request.  If the person on the end of the phone says otherwise, you just wait till you are outside of the 30 day 'fluffing' period.

 

Currently people can work if the internet is unavailable, by relocating if the internet is unavailable for what ever reason then no one can work.  Pretty simple answer really, don't put all the eggs in one basket and especially not reliant solely on a VPN service.

[brwainer]

You *could* put an AD server out on the end of a VPN, but remember that the service you pay your ISP for is just to connect you to "the internet". Usually in between any two given locations on the internet the traffic goes through half a dozen or more different companies. Any one of them could have a failure or make a human error that causes the connection to not work for hours or days. yes you can call your ISP to report it, and if you pay for business class service they will probably care at least a little and try to talk to the other ISPs that they connect to, but in the end it isn't a problem your ISP can fix. Here's some examples:

• One of my permanent site-to-site VPNs connects to a friend one town over. Since we're on different ISPs, the traffic actually has to travel about 150 miles to the closest internet exchange datacenter, and then travels back. In the traceroute, I have my ISP, then "alter.net", then "level3.net", then his ISP. Once his ISP made some error that meant that they were effectively cut off from the internet. He basically couldn't use any service that wasn't running on an "edge" server within their network, or redirected through something like Cloudflare which has endpoints all over the place and then I believe uses their own internet connections to contact the website. This outage lasted almost 24 hours. His ISP is not the biggest, but its one of the big ones in the US.
• Another of my permanent site-to-site VPNs connects to my grandparents house 4 states away (about 250 miles). That traceroute currently has my ISP, "alter.net", "telia.net", then their ISP, but in the past I've also seen the route go through GTT, Level3, and Cogent. A few times the VPN has disconnected, but neither my ISP or their ISP had made any mistakes. By using traceroute and the "Looking Glass" service that nearly all the backbone providers have, I was able to find that one of the ISPs in the middle (Level3 I think) had no routes at all for my IP block (i.e. the block of IPs that my ISP owns that my own IP is a part of) at one of their datacenters. If I looked at other datacenters they have, then that route was present. Since my ISP thought that the route to the other address was supposed to go through that particular datacenter though, the packets got dropped since the router there had nowhere to send them (apparently there wasn't a "route of last resort" (default gateway) set up, which sort of makes sense given that this is a Tier 1 backbone ISP, they don't have anyone "above" them to default to). This was definitely the result of a human error, but of what nature I couldn't tell for sure. That situation lasted about 12 hours.
  
  For context, anyone who runs BGP and has more than one other ISP they connect to should always have a route for every single IP address that they might get (purists will say for every IP address on the internet, but if I'm in the middle of the US, I can group all non-North-America IPs into groups like "over the Pacific, "over the Atlantic" and "South America". But BGP is a complicated beast, and the operation of it amongst the big ISPs is cut-throat and political. With BGP, you announce the routes that you have available (the IP blocks that you can reach) along with some details about the route, like whether it is a block that you directly service, or if it will be passed off to other ISPs. You will likewise get GBP data from all the ISPs you connect to, and then you apply lots of rules to the data you get as you try to combine all the avialable routes to figure out the best one for each IP block. "Best" is defined by the rules, and this is where BGP gets mean. ISPs will manipulate their rules based on contracts and agreements between each other, and also based on whether they think the other party is being unfair (sending more traffic then they are accepting), the CEOs recently had an argument, and other reasons both technical and mundane. Theoretically its also based on which connections are the most congested or underutilized at the moment, but by the time they apply other metrics, a link will basically be used for given routes until it goes down or the metrics get changed. What this means is that for all routes for a given IP block to just disappear, as I saw with my connection to my grandparents house, someone had to have made a mistake while updating their BGP rules, either on the broadcasting side (e.g. my grandparent's ISP wasn't broadcasting the BGP route properly) or the receiving side (the ISP in the middle that had to set up the route).

Long story short, you can't rely on a site-to-site VPN connection to be up all the time, and if you have your only AD server, or worse the only DHCP server, on the other end, you are going to have issues on that one day that it just will not connect.

[Nikolithebear]

"Would it be possible to host the active directory on the hosted server and dhcp on the firewall?"

 

 

Yes.  

[Mornincupofhate]

Wait, are you giving them your server to host, or are you putting your files on their servers?

 

If it's just their servers, I would personally go with OVH over rackspace. Rackspace is overpriced and has shitty bandwidth caps; not to mention that they're slow as shit.

Just my opinion.

[Erkel]

RUN FOREST RUN.  That enough to give you a gist of what I think you should do?

[porterj5]

On 6/16/2017 at 3:55 PM, Mornincupofhate said:

Wait, are you giving them your server to host, or are you putting your files on their servers?

 

If it's just their servers, I would personally go with OVH over rackspace. Rackspace is overpriced and has shitty bandwidth caps; not to mention that they're slow as shit.

Just my opinion.

We are using their server and shutting off our server. Transferring all data and services the local server was handling to the hosted one.

 

Their original price quote was overpriced but they brought it down way lower than anyone else we talked to and included data back ups and server maintenance.  After accounting for what we would be paying for that with a local server we were only paying an extra $100/month for the hosted server and they gave us a 30 day period that we can cancel at anytime.  It seemed like a sweet deal.

 

However, after taking some information from this thread and doing further research and starting to test things out it seems less than ideal.  Currently having trouble with transfer speeds.  On our ancient internal network we are able to get 11 megabytes / sec. When I transfer to and from the shared folder on the RackSpace server I am getting about 70 kilobytes / sec with a lot of small files and about 600 kilobytes / sec with one large files.  Also, when restoring one of our largest client's QuickBooks file from the shared RackSpace drive it took over an hour and a half to get to 20%.  I have reached out to them to see if this is just how it is or if I have something configured wrong.

[Falconevo]

6 hours ago, porterj5 said:

We are using their server and shutting off our server. Transferring all data and services the local server was handling to the hosted one.

 

Their original price quote was overpriced but they brought it down way lower than anyone else we talked to and included data back ups and server maintenance.  After accounting for what we would be paying for that with a local server we were only paying an extra $100/month for the hosted server and they gave us a 30 day period that we can cancel at anytime.  It seemed like a sweet deal.

 

However, after taking some information from this thread and doing further research and starting to test things out it seems less than ideal.  Currently having trouble with transfer speeds.  On our ancient internal network we are able to get 11 megabytes / sec. When I transfer to and from the shared folder on the RackSpace server I am getting about 70 kilobytes / sec with a lot of small files and about 600 kilobytes / sec with one large files.  Also, when restoring one of our largest client's QuickBooks file from the shared RackSpace drive it took over an hour and a half to get to 20%.  I have reached out to them to see if this is just how it is or if I have something configured wrong.

Keep it in house, don't outsource unless you have the connectivity required to allow it.  I work in enterprise hosting, I can assure you that you are best off keeping it in house for now

Site to Site VPN will chop the data throughput significantly as it reduces the MTU and adds a large portion of overhead.  If your line is already busy dealing with end user internet access etc as barbara from accounts needs to upload pictures of her pug to Facebook :>

[Mornincupofhate]

6 hours ago, porterj5 said:

We are using their server and shutting off our server. Transferring all data and services the local server was handling to the hosted one.

 

Their original price quote was overpriced but they brought it down way lower than anyone else we talked to and included data back ups and server maintenance.  After accounting for what we would be paying for that with a local server we were only paying an extra $100/month for the hosted server and they gave us a 30 day period that we can cancel at anytime.  It seemed like a sweet deal.

 

However, after taking some information from this thread and doing further research and starting to test things out it seems less than ideal.  Currently having trouble with transfer speeds.  On our ancient internal network we are able to get 11 megabytes / sec. When I transfer to and from the shared folder on the RackSpace server I am getting about 70 kilobytes / sec with a lot of small files and about 600 kilobytes / sec with one large files.  Also, when restoring one of our largest client's QuickBooks file from the shared RackSpace drive it took over an hour and a half to get to 20%.  I have reached out to them to see if this is just how it is or if I have something configured wrong.

Switch to OVH. Their top-tier servers are only $70 / month. You get gigabit download and 500Mbps upload with a 40TB data cap. Face it, rackspace is shit.

[Falconevo]

3 hours ago, Mornincupofhate said:

Switch to OVH. Their top-tier servers are only $70 / month. You get gigabit download and 500Mbps upload with a 40TB data cap. Face it, rackspace is shit.

Switching to OVH is going to make no difference in the problem faced, however it would cost considerably less  

[Mornincupofhate]

2 hours ago, Falconevo said:

Switching to OVH is going to make no difference in the problem faced, however it would cost considerably less  

He said it took over an hour and a half to get to 20% on a file transfer to his rackspace machine. Obviously bad network on their end.

[leadeater]

7 hours ago, Falconevo said:

Site to Site VPN will chop the data throughput significantly as it reduces the MTU and adds a large portion of overhead.

MPLS to the hosted server would kick traditional VPNs ass performance wise but good luck getting anything like that at a cut price .

 

@porterj5

Using hosted solutions for essential network services is only advisable if you have a dedicated, SLA guaranteed, connection between you and the hoster and you know what your network path is and who is involved with it which preferably is only 1 provider with 100% control and ownership over it.

[Falconevo]

9 hours ago, Mornincupofhate said:

He said it took over an hour and a half to get to 20% on a file transfer to his rackspace machine. Obviously bad network on their end.

I can assure you with 110% certainty, RackSpace do not have bad connectivity.

[porterj5]

Yea, I think I am going to have to cut bait on this solution.  There seem to be too many things to create issues and cause downtime.  Thank you for all of your help!

[NZLaurence]

 

On 2017-6-16 at 8:15 AM, Falconevo said:

1. Have a domain controller on site at all times in the event the site to site VPN is down you will have no one able to login. 

This is not actually correct. I have been involved is quite a few of these sorts of moves where the internet is good enough (we did this on private VDSL connections with 75/35 speeds for a small office but with most as 100/100+).

 

If you setup your AD sites correctly then the PCs know they are on a wan connection and will cache logins. This allows uses to login without a DC if they have logged into that PC before. This combined with cached files/branch office direct cache can make for a good experience if the workload is suitable.

 

With your internet speed i would be inclined to have a dc onsite replicating to an offsite one. Or look as hosted desktop as suggested. Either way you need to lose that 2003 DC asap.

[Falconevo]

1 hour ago, NZLaurence said:

 

This is not actually correct. I have been involved is quite a few of these sorts of moves where the internet is good enough (we did this on private VDSL connections with 75/35 speeds for a small office but with most as 100/100+).

 

If you setup your AD sites correctly then the PCs know they are on a wan connection and will cache logins. This allows uses to login without a DC if they have logged into that PC before. This combined with cached files/branch office direct cache can make for a good experience if the workload is suitable.

 

With your internet speed i would be inclined to have a dc onsite replicating to an offsite one. Or look as hosted desktop as suggested. Either way you need to lose that 2003 DC asap.

Caching any credentials is bad news for anyone security conscious but yes you can certainly configure it in that manner if you bare no regard for environment security.  I did suggested a minimum of 30Mbit/s upstream earlier in the thread for what he was trying to achieve along side general users internet access etc.

 

All my personally managed infrastructure has cached credentials disabled by group policy as security should be the primary concern of any domain administrator.  Each to their own though, It certainly wouldn't be a recommendation from me.

[NZLaurence]

58 minutes ago, Falconevo said:

Caching any credentials is bad news for anyone security conscious.

 

All my personally managed infrastructure has cached credentials disabled by group policy as security should be the primary concern of any domain administrator.

It depends on the location. Generally a blanket disable of cached credentials causes more issues then it solves.

 

For example laptops that roam will end up being a nightmare without cached credentials. Also the way the creds are stored makes it very hard to copy and crack a password from a PC and a practical impossible if bitlocker is on (remember cached creds can't auth remote connections to that PC, they are local log in only).

 

We have found from a security standpoint forcing password changes, complex passwords, no admin rights anywhere, gps to disable ntml and smb1, force bitlocker on for everything we can (and upgrade the PCs that can't as a priority) works pretty well. Also using creds tied to ad site locations limits the attack scope.

 

From our studies its a bigger risk to have a server sitting in a small site then to enable caching and a subset of services.