Getting scarily close to Summer and our entire new network setup.
by, 22nd April 2012 at 09:44 AM (10325 Views)
I'm confident enough to say it'll work well. But there's always that little nagging doubt in the back of my mind; the bit that says OK, this was my idea and the majority of implementation and testing is down to me and me alone. If it goes wrong, I'll never hear the end of it!
Anyway, after many successful years of CC3 (I only joined about 16 months ago, personally though) our school has decided to take the bull by the horns and update just about everything. A choice that started in our department mostly catalysed by the end of support for Windows XP and no doubt CC3 soon after. CC3 has been pretty much solid, it's been easy to manage and problem solve, and I consider myself fairly good with it. I've had some of the best tutors in the country though before this particular job and to those guys, I'm internally grateful. You know the sort of person, the type of guy that's easily forgotten more in the last week than you believe you'll ever actually know. Despite that experience, I've still kept learning about it and can honestly say that it really is a decent educational network system. It had it's difficulties like CC4 did, but maturity and the length of service from XP has certainly helped.
We looked at many options. We're a fairly large secondary school with the added complication of having a split site, one campus is a good 800m away from the other, connected with single mode fibre between them. That, and having only 3 of us to manage it all, that's relatively few staff juggling between two large sites. So far it's worked OK, many thanks to a fairly reliable system, some reliable computers and a good existing infrastructure of support. Some things need tightening up such as use of our helpdesk, but efforts in the last few weeks have improved this massively.
So, what options did we have?
Firstly, what's the goal.
1. A modern network.
2. Windows 7 on the clients. Throughout.
3. Retain the ease of maintenance.
4. Increase reliability and failover.
5. Increase performance.
6. Give staff confidence in the network and the use of computers in school.
The first was CC4. This seemed like a good natural evolution, we wouldn't have to have much more training and I personally had a lot of experience with it, both implementing it as a system and using it as an end user/administrator. We toyed with this idea a lot; soon after joining my school I took the Network Manager to one of my primaries that insisted I continued supporting them and their CC4 network to take a look at just what it was capable of. He came away impressed, the flexibility offered over and above CC3 was huge and many of the processes were just so much easier. Building stations was better, packages was similar/better depending on how you imported them, software/update allocation was a huge amount better. We were all aware of some of the difficulties CC4 has had, and in my old job I had seen more than my fair share of schools having extreme difficulty, to the point where they were refusing to pay RM any money until it was solved. However in this particular primary, I oversaw the installation, planned it, planned the implementation in the classrooms etc and to this day it runs with very few niggles. It's been solid.
The second choice was a vanilla network. This seemed like a good option on the price front, we were aware that budgets are tight and all 3 of us could manage a vanilla network with no extra training (but all agreed that training certainly wouldn't hurt, if we could budget for it!) Some of our existing network is already vanilla - the way some parts of the ICT system worked meanted that a separate network for music/media seemed appropriate, and it does work. So we're all comfortable with GPOs and logon scripts, but it does come with a level of fiddliness in network planning, implementation and maintenance. So of course, we needed to look at management options on top of this. Price naturally rises as you add options, the one that stuck out most of course was Impero - we'd seen what this software is capable of, we'd see trials and heard of it's reputation here on Edugeek of course. However it wasn't the only answer to resolve this particular problem, yet we'd come back to it later...
So where did we go?
After much staring at the numbers for CC4, we decided that perhaps cost would be a stalling point. It wasn't unaffordable, but we'd also had our eyes on the Microsoft EES licensing scheme. They would have had little to do with eachother, but EES gave rise to other options - the Microsoft Enterprise suite, notably SCCM. We played a bit with SCCM 2007 however found it very pinickity and awkward, and of course were aware of 2012 being around the corner (this was about a year ago). We knew what it was capable of, we knew a nearby school was using it with good success and decided to invest more time in testing it.
Roll on to April 2012.
At the start of the month, we're panicking. We wanted to get this done for Summer this year, but we couldn't do it on a release candidate of the software. We'd done lots of testing on RC1 and 2 and were extremely impressed with it's capabilities and power - both of which were far, far beyond what we would ever use, however it's so configurable and cost effective, plus with the EES scheme gives us scope to keep up to date, but really didn't want to have to wait another year. We drew ourselves a deadline - end of the Easter holiday for it to be released. We'd heard the same rumours as everone else, it'd be here during the MMS 2012 summit. Mid April, that was doable. Yet thanks to a post on Twitter via #sysctr we found it released far earlier. It was time to start implementing.
Installation was smooth as pie - the main systems both run on ESXi, so it was just a case of rolling back the snapshot before the SCCM RC's were installed, and carrying on from there. Completely separate from the existing domain name, we decided a fresh start rather than any form of migration would be the best move. ADMT will probably be used to shift over users when the time comes. Plus, I'd had plenty of experience installing SCCM 2012 now, with the betas and release candidates I knew the foibles regarding the SQL install and could easily install it now without the excellent documentation available at Portal - www.windows-noob.com. Never-the-less, I decided to use the documentation there as my implementation docs, taking out everything unnecessary, adding my own notes as I went along. All went entirely smoothly.
We've just decided on the rough infrastructure - there will be 2 new servers replacing the 3 CC3 servers. One on each site, the primary SCCM server also being primary DC, SQL server and user-store, and the other site pretty much just being secondary DC, backup DHCP, DNS, users and distribution point for that site.
One AD site set for each site (it was flat before) with a split IP range which would help with both the distribution points, keeping load off the inter-site link and better yet gives rise to a decision we made last week - using DFS with replication.
We've had a few problems in the past where if one server goes down, the users on it are unable to use the network unless they have a cached login somewhere. This can cause a major annoyance, and depending on the reason for the downtime can also cause major problems; for instance if it's not a quick job, we could move users to another server. But not all users, that takes too much time. So who do you decide is more important than the others?
The use of DFS, we believe, should be able to solve this. User storage isn't an issue; storage is still dirt cheap comparitively, and having to have 2-4TB of storage on each server rather than on just one isn't a difficulty. Users can go between both sites and automatically use the server closest to them, eliminating so much load from the site link. Should one server fall over, all we have to do is point the DFS namespace to the other server so if an issue is picked up straight away, we could have them back up and running in just a couple of minutes rather than "when the server is fixed"
SCCM 2012 is *massively* powerful. It can look a little too daunting perhaps from the POV of someone that's been dealing entirely with educational networks with CC3/4/Ranger etc installed, but with a little digging and removal of unnecessary clutter, you start to realise just how similar some of it is. There is a wealth of guides out there, including the excellent blogs on these very forums by @TheScarfedOne which will get you up and running in no time. I think it's certainly worth firing it up on a VM at home or at work just to get an idea of what it looks like and what it can do, because it could easily shape the future of your network.
So, I'm still nervous, yet we're so close to seeing something so futuristic compared to what we have now, I'm also massively excited. We're all looking forward to seeing how things run with this, we've all had input into it's implementation and design and just hope it doesn't get us all sacked CC3 isn't perfect, it does have limitations and many of the non IT staff are aware of that, so many of those are also looking forward to the changes. Of course there's a few staff that don't like changes but that's only natural; I look forward to helping them find their way around in the vain hope that they might find it a little bit easier, more intuitive.
I hope this will fulfill our goals set out near the start of this blog post. I expect September 2012 to be massively busy, and I will consider it a success if when we come back in January 2013 to have a helpdesk which is manageable and we can still have time to discuss new projects rather than existing problems. The months between September and Christmas 2012 I forsee will mostly be getting people used to the new network and resolving those teething issues that we didn't see during testing and implementation.
Total Trackbacks 0