Stuclark

I'm not going to do prices as that's a very complicated issue; but in terms of why virtualise or use physical servers: Presuming you have more than one physical host, virtualised servers will benefit from some redundancy Presuming you have enough horsepower in your physical hosts, you can create way more virtual servers than you'd have physical space for in your server room Virtualising servers (where the number of virtual servers is higher than the number of physical servers hosting them) reduces the power consumption, space needed, & electrical consumption of the server room Virtualising servers makes better (more efficient) use of your physical hardware. However ... To virtualise "well" you need some very powerful host servers, so the cost of buying those (and you'll still need to upgrade them every 3/4/5 years) may well outstrip the cost of buying less powerful physical servers. You'll also need a SAN to "properly" virtualise your environment. You'll then need to upgrade that 3/4/5 yearly too.

1. Yes 2. Yes 3. Leave it as it is 4. That's pretty much it. I trust you're going to use AD integrated DHCP too? One thing though - make sure you clean up your DNS as much as possible before integrating it. Get rid of any stale or dead objects.

We have 500 virtualised desktops; and they are hosted on 5 servers with a total of 320 cores and 1920GB RAM (64 cores & 384GB RAM in each server). The servers all boot off an SD card and everything lives on our SAN. (sorry, but SANs are the only really sensible solution for reduncancy). We have another 4 identical servers to host our virtualised servers. What this should tell you is that the spec you need is the highest you can possibly get - never, ever, ever work down to a price; instead look at what you need and then work out how to make the finances work (like buying in pieces, as you've said)

We have roughly 66000 addresses available on our wireless; but only see aprox 1000 active clients at any one time.

Yes, generally speaking we've found Apple TVs to be more reliable when on seperate (departmental) VLANs. In our environment it means we can effectively guarantee no more than 50 devices on any one Apple TV VLAN at any one time; which helps cut down on the Bonjour traffic enourmously. We use a seperate SSID for each VLAN, so have VLANs and SSIDs for Physics, Chemistry, English etc. Apple TVs are more reliable when hard wired; but that presents issues with the teachers not knowing what network / VLAN they are on; as the Apple TV has no way of showing this.

There's a setting in GP for synchronous / asynchronous execution of GP elements - make sure your script is running as a GP element, then enable synchronous execution - that will force the next GP element to wait for completion of the previous one

That's our Mac technician's desk - one Mac (with second monitor) is his admin machine; the smaller Mac is his test / dev machine. On the windows side of our network, I have an entire 42U rack dedicated to our test lab

4 of us in the main bit - 2 in the bit to the right back of the picture

You don't *need* to be using VLANs for printers, VOIP, APs etc. unless you want to enable some form of QoS on them (e.g to allow a higher preference for VOIP than printing). Again, you don't *need* to specify IPs on your VLANs, but if you intend to allow routing between them, or to allow them to use the same DHCP server, it may help to have IPs set so that the core switch can be the gateway for all of them, and so you can configure DHCP helper addresses. We have just over 30 VLANs at the moment (mostly used to separate AppleTV traffic); some of which route through our core switches and some through our firewall - the ones going directly to our firewall are the ones we don't want to have any access to internal resources i.e. our student and guest wireless LANs.

I think this AppleTV naming issue is an iOS8 / latest AppleTV OS issue - all our AppleTVs are on static addresses, but even having cleared DNS caches, we are getting the AppleTV (2) issues.

Your easiest bet is to use different SSIDs attached to the different VLANs.

The way I understand it is that they won't have to actually log in to SIMS. To authorise an (AD / SIMS) account to use the Teacher App, that account must be linked to a Microsoft or Google (or at some point in the future Office365) account; which will in turn be linked to a particular iPad. The user will then unlock their iPad using their Apple code; log into the SIMS Teacher App using their Microsoft or Google account; then, if configured how Capita recommend, sign in to the Teacher App one more time using another numeric PIN. This numeric PIN will expire every 12 or 24 hours, meaning they have to think of and remember a new one every day. (I'm not sure if you can re-use the same one, but it would seem to be a security hole if you can) The apparent advantage of this is that the SIMS user details don't get passed around anywhere...

Although Capita say it is, Office365 authentication is currently not supported or available, for use with the Teacher App. I've just had Capita confirm this is the case - they say Office365 support will be available "in the coming weeks"

We host all our DNS ouselves (using a 3rd party for resilience) - it took us about 6 months to finally get our 2 domains out of Capita / Openhive. It seemed that no-body at Openhive actually understood how to transfer a domain name!

Phil, could you please tell us when "soon" is - I'm getting pressured to implement the Teacher App, but having just created an Azure sync'd copy of our AD into Office365 for all our staff, I'm not now going to manually create each of them a Microsoft account (which has no password sync / which I can't control in any way etc.) purely so they can use an app whilst in our school, on our network, accessing a locally hosted, AD authenticated, network resource (SIMS).

Office 365 doesn't have the same 3rd party backup solutions as Google Apps / Drive do. AFAIK no one is doing a sensible solution for backing up things like Exchange Online DBs, as MS won't give direct access to them for one thing. Also, having an on-site backup of a cloud offering is sort of missing the point ... you'd still have to invest in lots of local storage to host your backups. And if you're intending to use a cloud backup solution to backup a cloud solution - do you know where that backup data is being stored?

Bear in mind that the standard Office 365 retention period for deleted emails etc. is only 90 days! Yes, it's possible to turn on the litigation hold options, which theoretically keep data for ever, but when we asked MS directly whether this could be turned on by default, and for an entire Exvhange organisation, they simply didn't know. ... for this reason alone, we've decided to keep all our email in-house.

I would steer clear of Sharp & Toshiba for build quality alone Ricoh were good when I last did a large implementation (over 200 machines) Canon are getting better after a while in the wilderness OCE are ok, but a bit flakey at times

I would rather block access to USB devices for our staff as well as our students and thus force them to keep all data on our on-site controlled, secure, backed up and resilient storage rather than having it on some other service that I have no control over. As that's maybe not achievable (the blocking USB bit) what I am doing is providing them an on-site data storage / retrieval service that is available widely enough for their needs, while still retaining all the security and control that I want.

Saying "Google have the OK from the Department for Education for use in schools" is not the same as saying "it's perfectly safe, secure, and a good idea to put all your sensitive data on someone else's servers, under their control, with no control over where that data is stored or what is done to it". OK, so that second statement may be a little over the top, but that's the consideration - as soon as your data is on a cloud, if that cloud is not one you own / have built, then you ultimately don't have full control over that data. As has been said above, this may well be absolutely fine for curriculum data as the chances are that data is not going to be confidential and the same content may well be publicly available elsewhere (i.e. online textbooks), but it certainly *isn't* fine to put sensitive, security dependent data on what is essentially a public cloud. We have looked at cloud storage for some of our data, and while we are going to use it, it is going to be only for students' data and for non-sensitive data that the teachers wish to access at the same time (a-la Sharepoint). The rest of our data is remaining in-house; and our sensitive data isn't even going on a system such as Firefly which would allow authorised access from outside our building. ... Also, don't under-estimate your backup / restore requirements - Microsoft (via Office 365) were able to offer us only a 90 day data retention period - for staff emails this is simply not good enough (by our estimates we'd need 15 years to be fully compliant with the letter of UK law), and what are you going to do when x or y student says "can you get that document back I deleted last year?" ... its simply not possible...

Guest Portal is a bit of an art, but once you realise how it works, it is simple as chips! The main thing to realise is you have to configure the portal through the online cloudwifi.com page, rather than trying to do it on any "local" device you may have. We've got a fairly large AirTight installation (120 APs currently online) and while we've had a few teathing issues, AirTight have been very good at supporting us.

We've had hundreds of these emails - just delete them!

Of course, as long as everyone keeps mixing up the two very different issues here, confusion is going to rein! The "issue" of having only an 8Mbps internet connection means things are going to be slow downloading / browsing the internet. Thus Apple updates and things that come from the internet *for every single device* are going to fail. Yes, a local caching / proxy server of some sort will help to cure this. The other issue, the one of AirPlay not working reliably, most definitely *IS* related to Bonjour traffic. If you have "40 Apple TV's (which are all air played too all day long) , 120 Apple Macs and almost 200 iPads, with all our printers (40+) [and] another 300 Windows devices" on a flat network, then I'm surprised you're not seeing network flooding issues caused by Bonjour. It could be because your network backbone is slower than ours (ours is 20GBps to each edge switch plus 1GBps to every device) or it could be that you don't have all those devices broadcasting Bonjour all day long. For the record, Windows computers don't broadcast Bonjour traffic around anywhere near as much as Apple devices do, mainly because Bonjour is not a feature of Windows unless you install some Apple software. From our extensive testing (over a year) we have found that for ultimate reliability, you don't really want to have more than about 60 Apple devices on the same VLAN / network segment, otherwise you will see some problems.

The whole point is you want to prevent any unicast packets getting out of the (local) network. So while they can be helpful in some instances, a Bonjour Gateway is not actually what you want here... As I said in a PM earlier today: I can't easily give specifics, because a lot of what you can achieve depends on what network (wired and wireless) hardware you have. We run HP layer 3 switches everywhere for our LAN hardware, so I have fully routable VLAN abilities on them. We're also running AirTight for our wireless (used to be Aruba), so with both of them I have the ability to create different VLANs and assign them different SSIDs (essentially creating seperate WLANs) and broadcast those different SSIDs on whichever APs I chose. The main points you will need to consider / work out are: To stop the Bonjour traffic you need to have small, independent networks. The easiest way of doing this is to use VLANs which have unique IP ranges, ensuring they are not directly routable from one to the other (without going via something that will block broadcast traffic). This is the key! To make it easy to use those VLANs, we then created "departmental" wireless SSIDs, so the "English" SSID connects to the "English" VLAN and can only see "English" AppleTVs. The "Maths" SSID connects to the "Maths" VLAN and can only see "Maths" AppleTVs etc. If your APs are layer 2 only, you will need to configure your DHCP server(s) to issue IP addresses on each of the VLANs you're using and enable that on your core switches (this is usually a switch setting - something along the lines of "DHCP helper address") and you'll need to make sure your default (untagged) VLAN is visible for DHCP traffic on all the other VLANs (if all your VLANs use your main network switch as their gateway, you can create mulitple virtual gw addresses on the switch and then your DHCP addressing becomes quite easy). If your APs are layer 3 or "tunnel" like Arubas do, then you can create your VLANs and DHCP ranges on the wireless controller. Once you've got those two elements set up, the rest should be quite easy.

From what I know of UniFi (which is not a lot I'll admit) it doesn't use multiple channels, hence why I didn't list them... that's all though.