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).