Duke

Updated link here as the TES one expired when they extended the application deadline: Whitley Academy | IT Manager

https://www.tes.com/jobs/vacancy/it-manager-coventry-1100472 Hi folks, I'd like to make you aware of a vacancy for an IT Manager at Whitley Academy in Coventry. The Academy are looking for a talented individual to lead a small IT team and manage the day to day running of the network. Lots of opportunities to get stuck in and work with the Academy and external suppliers to shape the IT strategy. All the details are in the advert linked above. The closing date listed is 13th but will be extended to 20th, however if you are interested then I'd encourage you to apply soon. If you want any specifics then contact the Academy or drop me a DM. Cheers, Chris

I'd agree with John and definitely look at Remote Desktop Gateway. Depending on how many concurrent users you need to support and what software they're running, I'd back it with a couple (or more) of RDS servers. These can be virtual, although for best performance when supporting lots of concurrent users you'll generally want them to be physical. At a minimum you'll need three servers (arguably two but I wouldn't recommend it), which can all be virtual if you don't need massive levels of performance or a huge amount of concurrent users: 1. RDGW - This your RD Gateway server which needs port 443 open to the internet. I'd also make it your RD Connection Broker server and use it as a general RDS management server for mapped start menus/desktops and RDS profiles. 2. RDS-01 - Your first RDS server, with all the software you need installed on it. 3. RDS-02 - Your second RDS server to provide some resiliency, redundancy and failover, configured identically to RDS-01. RDS-01 and -02 form an RDS farm that talks to the Connection Broker and is accessed via a DNS Round Robin name. For licenses you'll need server OS licenses, you may need extra licenses for some software, and the main bit will be RDS CALs (sold per device or per user). That'd give you a nice, small, reliable remote access solution which can be accessed remotely via PC, Mac, Linux, Android and iOS, and can also with a bit more work allow you to publish specific applications (rather than a full desktop) remotely too. If you needed to scale it out to support more intensive software and more users (up to about 100 per server) then I'd recommend making the RDS servers physical and with lots of CPU cores and RAM. Alternatively I'd look at VDI, but it sounds like overkill for what you're describing. Cheers, Chris

If it's just Office apps then with a sensibly specced server you should be reaching the upper end of those numbers. The chances of everyone being logged on at once are probably slim, but you'll know better than me in your environment. If you'll be using the remote access system to support school closures and snow days then bear in mind that this can lead to large numbers of people logging on at the same time. Spec-wise: As much RAM as your can throw at it. 16GB DIMMS are cost effective these days, so look at at least 48GB RAM, and 64GB or 96GB if you can afford it. You'll want dual socket processors with the fastest clock speed and as many cores as you can afford. The latest-gen Intel CPUs are very good value for money. Disk capacity normally isn't too much of an issue, just enough to install your application stack with some breathing room. More important is IO performance, so a pair of 10k or 15k SAS disks in RAID1 or four disks in RAID10 is usually sufficient. I would definitely go physical rather than virtual if you want to scale this to the max number of users possible. Virtual RDS servers are certainly feasible, but in a multi-user environment you don't want the additional overheads (however small) caused by virtualisation. Virtual RDS is fine for smaller deployments, but I'd avoid it in the scenario you're describing.

I'd agree with the previous posts. Yes it's possible up to a point, but for the infrastructure needed I don't think you'd see much in the way of cost savings, and it's unlikely that you'd get better performance than desktop PCs. Take a look at APEX and GRID cards, but they're not cheap.

Depending on what your application stack looks like, you can get 50-70 users on a modern, well-specced RDS Session Host. Obviously if your student applications include anything particularly RAM, CPU, disk or network intensive then this number will go down, but for typical office/productivity apps this number seems reasonable. We've got customers running RDS servers with near 100 concurrent users on them with no problems. Bear in mind that if you go over 32GB RAM (which I'd recommend) then you'll need Enterprise rather than Standard licenses for your RDS servers. Going by your numbers (25 users x 10 servers) I assume you're looking at supporting about 250 users? With correctly specced hosts you could drop this down to 3 or 4 servers rather than 10, which hopefully sounds a bit more reasonable.

That's very awesome, nice work! Nice to see so many Sun boxes in there too, good kit.

Cool, maybe just leave the non-production one running but not in use for a while to make sure it doesn't suffer the same problem. If it does crash too then it definitely points to something bad in the environment.

How much work would building a new VM and transferring data across be? If it's not giving you any indication why it's crashing then it might be the quickest fix. Have you got anything else you can rule in/out? Remove any unneeded virtual hardware from the server, upgrade VMware and VMware tools, build an identical server (from scratch, not cloned) and see if it crashes?

What OS is the server running? The Resource Monitor tool built into Server 2008 is pretty good for checking general health and making sure there aren't any obvious bottlenecks. Perfmon is also a good one as you can check general CPU/RAM usage while also monitoring disk usage, queue lengths, etc. which may be particularly relevant on a SIMS server. You can leave perfmon running then check the results over a period of time too. Saying "is blatantly obvious to him is that our SIMS server is really struggling" means nothing without some context, and Capita are hardly ones to talk about utilising resources well... I'd push back to them and ask exactly what they're claiming the performance issue is. What's the server spec, how big is the SIMS DB and roughly how many users access it?

Woo, nice one! If you've got hot-swap drives then you shouldn't need to shut down in order to remove/add the drives, but better safe than sorry if you're not sure. Glad you got it sorted out.

Hmm, if the replica runs fine then it does suggest it's being caused by interaction with something on the network, weird one though. What does the server do? Seen bad printer drivers and print spoolers and things crash servers in the past.

Shall keep my fingers crossed for you sir.

Nothing else in the logs prior to it crashing? Any scheduled tasks that run around that time? Could you clone the VM, power it up without networking, then see if they both crash or whether just the 'live' on crashes? This might tell you if it's something wrong with the VM itself, or whether it's triggered by interaction with something else on the network.

What hypervisor are you using, and have you got all the guest additions (e.g. VMware Tools) fully installed and up to date. Was this a fresh virtual build or was it a P2V?

I've seen this work before in theory like you've described, but I've also seen it go horribly wrong. Are you confident that your backups are good and will restore as expected? If so then I'd be tempted to say just create a new array from scratch with the disks/size/RAID type that you want, and then restore the data. If you do try it through RAID expansion, the process is usually something like: Replace one existing disk in the array with larger disk Allow the array to rebuild until it is completely healthy again Replace next disk, and repeat steps 1 and 2 until all the disks have been replaced with larger ones and the array is healthy Go into the array controller BIOS (or Windows-based GUI tools) and expand the array to make use of the larger disks (note - this isn't supported by all RAID cards) Once the array is expanded and healthy again, go into Windows disk management and expand the disk volume to make use of the newly available space (if the OS isn't Windows or you run into problems, check out GParted) Cheers, Chris

Veeam would tick a lot of boxes for you on the software side. It obviously does disk backup very well, has vendor-independent cloud support, and if you wanted to take the tape route then support for that is coming in version 7. Having used Veeam a lot I love it compared to products like Backup Exec. Obviously if you're 90% virtual than that other 10% still needs to be considered. As far as the whole solution goes, Veeam running on a beefy server (it'll use plenty of CPU and RAM if they're available) with lots of local disk for backups and the Cloud edition to pipe it out (encrypted) to the provider of your choice seems like a valid solution. You could hang a tape library off the back and wait until Veeam v7 and use that for offsite backups if your internet connection wasn't up to the Cloud solution. Cheers, Chris

How many desktops, how many users, do you want remote access (from outside of school) too, how much have you got to spend, and most of all... what do you want to achieve with VDI? Lots of options out there at varying price points. What have you got in the way of hardware at the moment (desktop and server) and are you planning/wanting to re-use any of it?

Cheers. Yep, we do a lot of this type of thing and support a lot of schools (and other organisations) with Thin Clients. There's a lot of things to consider and we'd need to look at all the aspects with you - cost (initial and ongoing), performance, manageability, what you want to achieve, etc. 100 machines can certainly work with thin clients, but it would depend on what you want to spend and what your expectations are compared to the current fat clients. Drop me a PM or get in touch via our website (Contact Us - Cutter) and we can have a proper chat about it.

Cool, sounds good! Just post in here or make a new thread and PM me if you get stuck, I'm sure someone will be able to help. Good luck with it all, Chris

Ok, looks like we're not going to agree on any points here so I'll leave it. I was merely trying to make the point that although VDI clearly hasn't worked for you, and that you don't need a physical SIMS server, DC or 10Gb, those things aren't true for everyone.

Ok, not looking to get into an argument, just offering my observations. Yes, up until very recently I used to work in a school. I now work for a company that does (amongst other things) big VDI deployments and we've had success with them for many years. I only say that to point out that VDI is out there and does work for people. I'm a little confused over your argument of VDI vs Terminal Services, I see them as the same thing just using different protocols: Wikipedia - Desktop virtualization. Are you referring to "Terminal Services = Thin Clients pointed towards TS/RDS servers" vs "VDI = thin clients pointed towards a dedicated VDI provider like VMware View"? If so then we use both, depending on the customer's needs. Sometimes VDI with Terminal Servers is the best option, but I'd still call that VDI. Maybe I've misunderstood you? Re SIMS - Yes, they do support it now, but not everyone may realise that which is why some people might still be wary. Also, not everyone can afford a SAN like yours, but do use SIMS really heavily. If your SQL server is running lots of things besides SIMS and you've got a decent SQL server already, why virtualise it on to storage hardware which may not be able to keep up if it's doing lots of other things? If you've got a good SAN or are using fast local storage and don't hammer SIMS, then I agree, virtualise it. Re DC - Yep, in an ideal world nothing would depend on anything else and you could just power up the machines how you like. However, not everyone has an ideal set up like that, or maybe they're using hardware/software that at some level requires AD/DNS/DHCP and there's nothing they can do about it. Maybe they've still got other physical servers for other applications that can't be visualised, and they don't want to lose AD authentication if their virtual infrastructure goes down. If you can avoid that then great, but not everyone can, and so having the physical DC is useful to a lot of people. Re Bottlenecks: It was a hypothetical scenario, thus the 'say', 'maybe' and 'likely'. No, that scenario probably won't apply to many schools, but I also don't know of any schools that have put 10Gb in either. Uni's supporting tens of thousands of users probably will find a use for 10Gb. I think I'm confused over the differentiation between pure VDI vs VDI using Terminal Servers. To me they're both VDI, and which one I'd use would depend on the scale of the customer and what OS they're running. I don't think there's any case where VDI in general is the only solution, but I do believe there's ones where it's the best (it might be for speed, for manageability, for data security, for device security/vulnerability/damage, for long-term costs, etc.) If you have the luxury of not needing access to AD/DNS if your virtual infrastructure is down. Not everyone has that luxury, or the ability/budget to make it so. Just because you don't need 10Gb, it doesn't mean no one does. I don't know of any schools that would require 10Gb, but like I said, I imagine the bigger unis probably do.

I'm going to play devil's advocate for a bit... I've recently started working for a company that have done a lot of VDI installs, and I can honestly say there are 1000+ seat VDI deployments that are a huge success, and that thin clients work much better for them than fat clients did. It all depends on the scenario, the users' requirements, and what their expectations are. We've got sites where staff can walk up to a machine, plug in a smartcard, be logged on in 5 seconds, unplug the card and be logged off instantly, then go home, go to a website, and log back in to their session from home exactly where they left off. We've also got sites with machines spread out over a wide campus, and the staff on-site would struggle with managing them. With VDI everything's central, and on the very rare occasion a thin client does break, it can either be fixed from the central server or the hardware swapped out in a couple of minutes. Is VDI suitable for everyone? No. VDI, if done properly, will lower your long term costs. Will it be cheaper in the short term? No, very unlikely. If you've got well-spec'd fat clients and are maxing out their CPU/RAM/GFX capabilities, then it's unlikely that thin clients will give you better performance. If you've got a site where the main use of PCs is Office, SIMS and browsing the internet, and they currently have very few or very old PCs, then VDI may offer a major improvement over what they've currently got. If you've got a new build and they need a huge number of PCs but can't afford to upgrade them every three years and need something that isn't going to get broken by users, VDI may be perfect. 1) Okay, using your first example of SIMS - I think most people say SIMS has to be physical is because for a long time Capita said they wouldn't support SIMS in a virtual environment, and no one wants their huge MIS system to be unsupported. Also, SIMS is largely just an SQL server, and SQL usually has fairly high disk I/O requirements (depends on how heavily you use SIMS). Disk I/O doesn't always virtualise very well, unless you have good local storage on your VMware/Hyper-V/whatever host (not recommended) or a good network link to your SAN with fast disks (expensive). Using your second example of a DC, it's more that you shouldn't have just virtual DCs, you should have at least one physical DC/DNS/DHCP server. The reason for this is simple - dependencies. Say everything goes down (long powercut or whatever) and your VMware/whatever host talks to the SAN via its hostname. You power up the VMware/whatever host, but it can't see the SAN because there's no server up doing DNS. You can't power up the virtual DC that does DNS, because to do that you need the host to see the storage. Same issue if something on the infrastructure side needs AD authentication for it to start up. You're stuck in a loop of dependencies that are very easily solved by having one physical DC. You can get around this by not having anything on your infrastructure that uses DHCP, hostnames (rather than IPs) or AD authentication, but most people just prefer to have a physical DC/DNS/DHCP server that they can power up first, and then start up their virtual hosts and storage. 2) Bottlenecks - Say I run 20 physical servers and they've all got 1Gb connections. Say they all peak at around 80%, and maybe half of them peak around the same time of day. If I virtualise all 20 of those servers and put them on one physical host with a 1Gb or 2Gb link, then at some point it's very likely I'll run into network bottlenecks that are (technically) due to the virtual infrastructure. I don't know anyone running 8Gb or 10Gb links, because in reality in a school very few of us are running that kind of network throughput. I do know people with blade chassis that have very high consolidation ratios and are coming close to maxing out 4Gb links though, and have a perfectly good reason to consider 10Gb networking. That's my two pence anyway. VDI can be absolutely awesome if it's put in the right place. If someone's got high-powered fat clients and swaps them for thin clients expecting a performance increase, they're probably going to be disappointed. If they want a new, manageable, large array of desktops and don't need video editing capabilities (or similar), then VDI may be perfect for them. You keep some servers physical to either avoid loops of dependencies or single points of failure, or because you can't afford the hardware needed to give the required performance on a virtual server. You do 10Gb networking if you need it - most of us don't. If you're consolidating a lot of physical servers down onto one server by virtualising them, then you need to provide sufficient bandwidth for all of those servers. For some people that might only be 1Gb, for some people that might be 10Gb. Like I said, just my opinion and just playing devil's advocate.

Most people don't have the time/space/money for tapes these days, so a purely-disk-based backup solution is entirely acceptable. Having said that, the arguably best-of-both-worlds solution is B2D2T - backup to disk to tape. You'd do your regular daily backups to disk overnight which are nice and quick, then you'd copy those backups onto tape (via a method that doesn't put any additional load onto your main network) during the day. You might onto put your weeklies onto tape, or you might have the time/space to put your dailies on there too. I'd suggest your weekly full and daily differentials go on to the SAN. They'll be quicker and you'll be able to do a full restore from disk if needed without having to play guess the tape. I'd then suggest you either find a way to do B2D2T, or do an additional backup straight to tape. How often you backup to tape is up to you, but if you had to do a full backup from tape (rather than just restoring an archived file), how long would it before before the backups were as good as useless? For example, if you did tape backups on a Sunday and everything died on a Friday, how would your finance/HR/whatever department feel if you told them you'd lost almost a week of work? Obviously ideally you'd backup everything all the time, but that's not really practical, so try to find a balance between what people want and what you can reasonably manage. If the QNAP is iSCSI connected to the BE server and the tape drive is also connected to the BE server, you should be able to push the backup data to tape on a schedule that suits you.

Yep, iSCSI is SCSI data inside an IP packet and runs over standard networking. I'd recommend a 1Gb minimum link between the QNAP and the Backup Exec server if possible. I was going to explain how to set it up, but QNAP have done it for me: QNAP - Resources - Tutorials - How to create and use the iSCSI target service on the QNAP NAS