Moving Forward: Converting a mess to the right solution
-
Looking over the thread Additional 2012r2 License Question Has me thinking of how I need to move forward to clean up this mess of a 'network'.
We won't have the need for Exchange with running O365, so mainly I will only need AD, File&Print services, and 2 SQL system and a app that is really Access DB - and backup services.
With that in mind, Is a single box (well built) box) with 2 VMs adequate for what I need? or should I spring for 4 VMs? My main concern and focus is getting AD with F&P going so I can move everything over and deal with some security issues, and retire some equipment.
Additionally, we have offices in 10 counties now. Which means quite a bit of upgraded hardware (Currently lots of WinXP) needed. Could I go ThinClient and host all of the apps (Office, files etc) here?
-
@g.jacobse said:
Looking over the thread Additional 2012r2 License Question Has me thinking of how I need to move forward to clean up this mess of a 'network'.
We won't have the need for Exchange with running O365, so mainly I will only need AD, File&Print services, and 2 SQL system and a app that is really Access DB - and backup services.
With that in mind, Is a single box (well built) box) with 2 VMs adequate for what I need? or should I spring for 4 VMs? My main concern and focus is getting AD with F&P going so I can move everything over and deal with some security issues, and retire some equipment.
Additionally, we have offices in 10 counties now. Which means quite a bit of upgraded hardware (Currently lots of WinXP) needed. Could I go ThinClient and host all of the apps (Office, files etc) here?
I've heard Thin Clients is kind of dead. Maybe I heard wrong but VDI is more what people are doing now. In any case...
One server for AD AND F&P would be fine. When you say spring for 2v4 VMs, are you talking about Windows Server licensing? Why use Hyper-V? Use VMware. However, that being said, if you do use Hyper-V, spring to have up to 4 VMs so that you have room to grow, should you need it. Maybe it's wasted, but the wiggle room is never bad to have. -
Thin clients are in no way dead. VDI has its place, but it doesn't eliminate RDS. A good box should be able to run many many VMs. The only thing that might affect your decision would be the SQL ones. Licensing and if the app that runs on that system likes to play well with others.
Be careful about running Office with RDS. There are additional, crazy licensing limitations that you'll need to address if you do it.
Lastly, don't forget backup.
-
@DenisKelley said:
Thin clients are in no way dead. VDI has its place, but it doesn't eliminate RDS. A good box should be able to run many many VMs. The only thing that might affect your decision would be the SQL ones. Licensing and if the app that runs on that system likes to play well with others.
Be careful about running Office with RDS. There are additional, crazy licensing limitations that you'll need to address if you do it.
Lastly, don't forget backup.
Ok, then I misunderstood or misread something. Good to know. As far as performance, yeah, SQL is gonna be the determining factor. Especially since you said you have two SQL instances, that's gonna be a bit of a resource hog. Your disk IOPS are also something to consider. Then again, if you run it all on one physical box with VMware, it's the same, except you aren't running VMs on top of Windows. It's a true hypervisor that way.
Also, in regards to the Office, licensing is one dragon to kill. The other is performance. You have thin clients setup or whatever and you have Outlook? Yeah, that slows WAY down...ask Danielle about a certain client in Carrollton that does that. Right @Minion-Queen ?
-
@DenisKelley said:
Thin clients are in no way dead. VDI has its place, but it doesn't eliminate RDS. A good box should be able to run many many VMs. The only thing that might affect your decision would be the SQL ones. Licensing and if the app that runs on that system likes to play well with others.
Be careful about running Office with RDS. There are additional, crazy licensing limitations that you'll need to address if you do it.
Lastly, don't forget backup.
Not to mention a VDI still uses a ThinClient.
a Terminal Servicer is much cheaper to run, and maintain, it should also be the first choice and then look at VDI solutions if something has a valid reason for not using a Terminal/RDS. for most clerical workers a terminal server will work just fine. -
@ajstringham said:
One server for AD AND F&P would be fine. When you say spring for 2v4 VMs, are you talking about Windows Server licensing? Why use Hyper-V? Use VMware. However, that being said, if you do use Hyper-V, spring to have up to 4 VMs so that you have room to grow, should you need it. Maybe it's wasted, but the wiggle room is never bad to have.
I personally would seperate out your domain controller and your File/Print Server. I would keep an AD server just being a DC only. and use another vm for File/Printer if budget allows.
Nothing wrong with using Hyper-V over Vmware it's a personal decision, choose what fits the business needs and you like. Remember you have to deal with managing it. Given all your hosts are windows I see no real disadvantage from what you've listed as needs with using Hyper-V.
-
@g.jacobse said:
Additionally, we have offices in 10 counties now. Which means quite a bit of upgraded hardware (Currently lots of WinXP) needed. Could I go ThinClient and host all of the apps (Office, files etc) here?
How many clients do you have? when you scale up is when Terminal services (or VDI if really needed) makes more sense, if you have a few clients it will not be cost effective.
-
@thecreativeone91 said:
I personally would seperate out your domain controller and your File/Print Server. I would keep an AD server just being a DC only. and use another vm for File/Printer if budget allows.
Yeah, when I started budgeting, I split all those roles out. A little extra money, but worth it. I can quickly reboot my Print or SharePoint server without kicking people off of files.
-
@thecreativeone91 said:
@ajstringham said:
One server for AD AND F&P would be fine. When you say spring for 2v4 VMs, are you talking about Windows Server licensing? Why use Hyper-V? Use VMware. However, that being said, if you do use Hyper-V, spring to have up to 4 VMs so that you have room to grow, should you need it. Maybe it's wasted, but the wiggle room is never bad to have.
I personally would seperate out your domain controller and your File/Print Server. I would keep an AD server just being a DC only. and use another vm for File/Printer if budget allows.
Nothing wrong with using Hyper-V over Vmware it's a personal decision, choose what fits the business needs and you like. Remember you have to deal with managing it. Given all your hosts are windows I see no real disadvantage from what you've listed as needs with using Hyper-V.
Considering AD has almost zero system load, is there really any reason to separate out AD from the file and print services? If anything, use the license of Windows server you would have used for File/Print on a secondary DC.
-
@ajstringham said:
@thecreativeone91 said:
@ajstringham said:
One server for AD AND F&P would be fine. When you say spring for 2v4 VMs, are you talking about Windows Server licensing? Why use Hyper-V? Use VMware. However, that being said, if you do use Hyper-V, spring to have up to 4 VMs so that you have room to grow, should you need it. Maybe it's wasted, but the wiggle room is never bad to have.
I personally would seperate out your domain controller and your File/Print Server. I would keep an AD server just being a DC only. and use another vm for File/Printer if budget allows.
Nothing wrong with using Hyper-V over Vmware it's a personal decision, choose what fits the business needs and you like. Remember you have to deal with managing it. Given all your hosts are windows I see no real disadvantage from what you've listed as needs with using Hyper-V.
Considering AD has almost zero system load, is there really any reason to separate out AD from the file and print services? If anything, use the license of Windows server you would have used for File/Print on a secondary DC.
It's not about system load, It's about priority/and potential down time and loss of services to end users. Your DC is always your most important server once implemented in a network.
-
@ajstringham said:
Considering AD has almost zero system load, is there really any reason to separate out AD from the file and print services? If anything, use the license of Windows server you would have used for File/Print on a secondary DC.
Yeah, little load, but rebooting is a likely candidate for separating the roles. A second DC is a good idea, but we don't know how large this company is.
-
@DenisKelley said:
@ajstringham said:
Considering AD has almost zero system load, is there really any reason to separate out AD from the file and print services? If anything, use the license of Windows server you would have used for File/Print on a secondary DC.
Yeah, little load, but rebooting is a likely candidate for separating the roles. A second DC is a good idea, but we don't know how large this company is.
A second DC is always a good idea. It's never really "should I have two DCs?" It's "when should I add a third?" Why is rebooting an issue? It's not like you'll be doing that during production time. It'll be during off-hours. Also, he said it's for ten counties, or more. I still say have your main DC with File/Print on it. Use the next license for your secondary DC, and go from there.
-
@ajstringham said:
A second DC is always a good idea. It's never really "should I have two DCs?" It's "when should I add a third?" Why is rebooting an issue? It's not like you'll be doing that during production time. It'll be during off-hours. Also, he said it's for ten counties, or more. I still say have your main DC with File/Print on it. Use the next license for your secondary DC, and go from there.
Because it might be silly to have 2 DCs for a company with say 5 PCs. Sometimes having the ability to selectively reboot a server has it uses. Not saying it has be split, but there are use cases for that.
-
@ajstringham said:
@DenisKelley said:
@ajstringham said:
Considering AD has almost zero system load, is there really any reason to separate out AD from the file and print services? If anything, use the license of Windows server you would have used for File/Print on a secondary DC.
Yeah, little load, but rebooting is a likely candidate for separating the roles. A second DC is a good idea, but we don't know how large this company is.
A second DC is always a good idea. It's never really "should I have two DCs?" It's "when should I add a third?" Why is rebooting an issue? It's not like you'll be doing that during production time. It'll be during off-hours. Also, he said it's for ten counties, or more. I still say have your main DC with File/Print on it. Use the next license for your secondary DC, and go from there.
Sure a Second DC is great but, it only provides a active backup for data. It's not going to be handing out DHCP/DNS on the network (or at least not on the same subnet) so their will still be down time.
It would be great if issues only happen after hours when no one would be bothered by them but in my experience they happen during the day. You don't want to have to restart your DC because of an issue on your file/print server. Sometimes printing issues require the server to be restart to fix not just the services. Are you going to tell the CEO he has to wait til the next day to print his golf dates because you didn't separate out the DC & File/print services? Remember in a organization with AD implemented well many if not most things will authenticate against the domain. not just the local login. You have to plan for issue that will occur, it's just when.
-
@thecreativeone91 said:
@ajstringham said:
@DenisKelley said:
@ajstringham said:
Considering AD has almost zero system load, is there really any reason to separate out AD from the file and print services? If anything, use the license of Windows server you would have used for File/Print on a secondary DC.
Yeah, little load, but rebooting is a likely candidate for separating the roles. A second DC is a good idea, but we don't know how large this company is.
A second DC is always a good idea. It's never really "should I have two DCs?" It's "when should I add a third?" Why is rebooting an issue? It's not like you'll be doing that during production time. It'll be during off-hours. Also, he said it's for ten counties, or more. I still say have your main DC with File/Print on it. Use the next license for your secondary DC, and go from there.
Sure a Second DC is great but, it only provides a active backup for data. It's not going to be handing out DHCP/DNS on the network (or at least not on the same subnet) so their will still be down time.
It would be great if issues only happen after hours when no one would be bothered by them but in my experience they happen during the day. You don't want to have to restart your DC because of an issue on your file/print server. Sometimes printing issues require the server to be restart to fix not just the services. Are you going to tell the CEO he has to wait til the next day to print his golf dates because you didn't separate out the DC & File/print services? Remember in a organization with AD implemented well many if not most things will authenticate against the domain. not just the local login. You have to plan for issue that will occur, it's just when.
Fair enough. I guess it goes back to the size of the organization, and how critical uptime is. No one likes downtime, no matter how brief. However, it's certainly true that it's more acceptable for some companies than others, and in different lengths.
-
@ajstringham said:
A second DC is always a good idea. It's never really "should I have two DCs?" It's "when should I add a third?"
The bulk of SMBs should only have one. DCs, of all things, rarely have noticeable downtime. NTG can go a week with the DC down and no one would realize it. The cost of downtime for many SMBs is literally zero. Even a day or two or ten. Some companies tie other things to AD that doesn't cache like logins and downtime can impact them. But a typical SMB can definitely take a few hours of AD downtime with possibly zero impact.
Considering that - the cost of a second server hardware (say $2K minimum) and another Windows Server license (say $750 minimum) and the electric and cooling to keep that running and the IT time to administer it. Likely you are talking $4K or more for a failover system that has no means of ever recouping its costs no matter how bad the outage(s) are.
There is pretty much no risk mitigation system that is an "always", especially in the SMB. The closest thing would be RAID 1 disks - if you are putting a disk in a server, it should be in RAID always... is almost true. But even that there are exceptions. Just very few.
-
@thecreativeone91 said:
Sure a Second DC is great but, it only provides a active backup for data. It's not going to be handing out DHCP/DNS on the network (or at least not on the same subnet) so their will still be down time.
It should be doing DNS and DHCP if needed. Secondary DNS is more important than secondary AD.
-
@ajstringham said:
I've heard Thin Clients is kind of dead. Maybe I heard wrong but VDI is more what people are doing now. In any case...
I think that you are confused as to these terms. Thin clients and VDI are not opposing concepts. All early and many current VDI implementations use thin clients. And VDI is in no way the "path forward." It has a place but remains an "only when other things are not an option."
Don't get caught in the VDI and Zero Clients everywhere hype. VDI is insanely expensive and an extremely niche solution for special cases. In enterprise where there is huge scale to make it pay off, VDI is starting to creep in more and more, but in the SMB, it has almost no place at all.
-
@thecreativeone91 said:
It's not about system load, It's about priority/and potential down time and loss of services to end users. Your DC is always your most important server once implemented in a network.
Quite often it is the least important, especially in an SMB.
-
Because AD and File Services are probably tightly coupled here, having them on the same VM makes sense. If you need to do a reboot, both go down and come back together. If there is a dependency of one on the other, which there is, then having them on separate VMs doesn't really help much.
I think that one Windows Server Standard license is adequate. Two VMs. Keep it simple.
