Ephelyon

Thanks, everyone, for your views. On the basis of that, do we think it might be a good idea to contact e.g. the BCS, or QA perhaps, see what could be done? Or is it unnecessary? Or maybe, if so, would GrumbleDook be better placed to do that, being on the Policy Hub and all? Incidentally, of those who have viewed the job specs I posted... does anyone have any comments?

I think that summarises it down to a tee, TonyJF. That's why I think a qualification that emphasises an understanding of teachers for techies will: * Perhaps finally get those few genuine control freaks in our profession to review their attitude, or at least weed out the ones who refuse to; * Make teachers feel better about coming to us instead of going over our heads; * Make senior leaders more aware of our skills and more confident in them; * Provide those of us (like me) with skills gaps with a school-friendly (both in marketing and in price) and targeted method of remedying this.

Thanks GD. I agree that FITS is a good thing, and I certainly wouldn't want it to go away, but indeed, as GrumbleDook says it isn't the full monty. I've also heard that some senior leaders are assuming that, as it was to a degree spearheaded by Becta, now that Becta's gone FITS is discredited as a methodology in itself. I wouldn't agree of course, but this preconception may still exist. I also agree that whatever tool is used (and SFIAPlus seems fine to me), a thorough review of all IT Support job descriptions in UK education - within all LAs, is absolutely necessary. In my LA, the job spec of Network Manager hasn't been touched for about 6-7 years. It still mentions Windows 2000. It makes no mention at all of the full responsibilities an IT department had back then, never mind now. It's completely useless, and I've recently finished a very comprehensive job re-evaluation (at my own request) to update the spec and make it a bit more accurate. It was fully agreed by the Head and the Business Manager, sent it off for re-evaluation and... it comes back at exactly the same paygrade. I'm appealing it at the moment as I think that since we've had the new technologies and the new responsibilities added over the past 5 years, it should be at least two grades up from when it was originally evaluated many years ago. It would seem on the face of it, though, that the LA won't agree. Added to that, I have had an ongoing debate with my Head as part of the job review to do with who does what on the strategic side. Ultimately he's the Head, so the final strategy is going to be up to him. We have a perfectly good understanding now, and neither of us is unhappy with who does what. I did hear at one point, though, when I presented my technical strategic plan for the year that I'd be developing and following, that "that's just the technical translation of what's in the SDP" and that it's all just there to support the overall teaching and learning strategy of the school. Which it really isn't. I mean, yes, bits of it are, but it also included elements like the back-end transition to server virtualisation, redeveloping our backup and Disaster Recovery procedures, upgrading from Server 2008 to 2008 R2, evaluating and implementing Exchange 2010 to replace 2007, patching up redundancy holes to make sure that "new" (for us) reliances like electronic registration can be delivered successfully, etc. These are all elements of IT strategy which is exclusively within the skillset of IT professionals, not ICT strategy (i.e. overall, how will we use the computers, where are we going to put new ones, etc.) which is part of the school's SDP and is exclusively the purview of senior leaders. I have made him aware of these elements now, and he accepts this - which is a damn sight more than some Heads would do (judging by many lamentations on this forum), so I respect him for that. I've attached the original and my approved reviewed version for people's reference (which I probably shouldn't do, but it may help to illustrate). However, getting back to the point, if you take those two examples... no, to be honest, I'd have to disagree, GrumbleDook. Great strides have been made, not least due to work on structures like FITS, often carried out and championed by people like your good self, but overall... no, I don't think the LAs recognise everything that we do with their job specs - I'll try my best with this job review, but I don't really expect it to get anywhere. And no, I don't think senior leaders recognise what we do either, overall - I mean, mine does now, but there was an entire rigmarole involved in explaining that side of things, and I imagine many people on here would agree that it wouldn't wash with their own Heads or Business Managers. I do think GD is right in that, yes, Academy groups and MSPs (though also state schools) could be persuaded to adopt this view... this is why I thought a single, unified accreditation might be a good idea, as we could market that on the basis that it's very specific to the skills that schools really need. In my experience, schools love getting things tailored to education! That might persuade them to support the future development of such a cause. Indeed - I would be very happy to join BCS or similar if it would champion our particular sub-vocation! It would certainly brass off people like bisley98 and johnbrown on those TES threads from way back when... aaae5012 - network manager (revised - nov 11).doc aaae5012 - network manager.doc

Agreed, alan-d. I think Becta had an ICT Competencies Framework that would seem to partially fit your scale above... For localzuk: Quite right, FITS is a good starting point and embodies many of the ideals I've expressed already (more than I thought it did in fact). However... Looking at the material on their Introduction, Practitioner and Advanced courses, it seems to be mainly technical and service management-oriented. Quoting from the Advanced course: * Servers and computers * Operating systems * Routers, switches and firewalls * Peripherals More specifically: * Directory Services Administration * Print & Output Management * Storage Management * Service Level Management * Service Continuity Management * Performance Monitoring * Preventative Maintenance * Energy Conservation * ICT Financial Management This is all well and good, but I was thinking more of a course with modules covering things like this, as well as e.g. things like projectors. Things like Safeguarding issues. Things like understanding the differences between "industry users in an office" and "educational users in the classroom". Two examples: * A question I apparently got wrong at a recent job interview was about Safeguarding, asking about the statutory procedure for what to do if you find an inappropriate image on a staff laptop. I got the answer wrong because no-one had ever told me there WAS a specific procedure. We manage the technical side of Safeguarding every day - my question: what else that's "official" don't I know? * Many people joining us straight from industry might be dismayed at certain teachers' apparent shock at being asked to replace a toner cartridge themselves if a new one is dropped off by the technician when the toner level reaches 5%. This is to avoid disruption in their lessons in case we're not available to change it immediately. Either way though, an understanding of pedagogy could be a module - for example, the fact that if this is a very difficult class, that teacher might be holding order together solely through the force of their personality and a 2-minute lack of concentration to change the toner simply isn't an option in all circumstances. This is something that you know if you're a teacher, or if you're one of us who's worked in education before, but otherwise I think it's something most people from industry looking to join education wouldn't understand at first. FITS doesn't seem to accommodate things like this. Yes, you could do some FITS stuff and mix it with a SWiS qualification, adding a projector training course and whatever other examples you can think of... but wouldn't it be nice to have it all as part of a single framework, endorsed by the government, accredited by the BCS and promoted to schools to raise understanding and awareness?

Hi all! I will start with a fair few paragraphs of waffle and (perhaps!) eventually wrap it up into an idea. I have been thinking lately about "where we're at" with IT in education at the moment. It occurs to me that, as has happened with many fields (or branches of fields) in the past, there comes a time when it needs to "professionalise" itself. Let me make it clear at this point that I do not mean to say that we "aren't professional" (bisley98, anyone?), merely that we often find it difficult to justify our knowledge, skills, experience, rationale or priorities to our colleagues because there is no clear source of this information for them to corroborate it with. In "the industry", many of these problems are mitigated by, in my view, a more developed understanding of the place of IT within, say, a corporation. It seems to me that the major ongoing issues might be summarised thus: * Pay not commensurate with duties; * Misguided attitudes from other staff (though this may be reciprocal!); * Profession not clearly defined; * No clearly-defined entry route into the profession; * Lack of training. In fairness to the current situation, 10-15 years ago IT was primarily a curriculum resource used to support and facilitate teaching and learning, with some admin workstations bolted on to use/manage the school MIS and etc. It has since evolved into a central resource - functioning at an organisational level - that enables the functioning of the entire school, including large parts of the curriculum and the majority of the administration work. There are many schools that would largely grind to a halt if the IT system were to go down for a day (or two). The difficulty is, most people in education don't know this. We know it because it's our job to know it, but how many schools that are lucky enough never to have experienced e.g. a total (though temporary) system failure before, or a catastrophic loss of data, have truly realised how dependent they have become? Can we blame them for not having caught on yet? In a sense, not really. Because, to be fair, there was a time when a school's IT facilities (or at least all most staff saw of them) were primarily there to support teaching. There was a time when an IT technician could quite fairly be classed as a member of the classroom support staff like a Science, Art or D&T technician and would quite reasonably report to a teacher. Nowadays the system is there to serve pretty much everyone, and additional managerial roles such as Network Manager have been created (which is a plus and we shouldn't forget the recognition we've managed to glean there). The priorities are different; the balance of necessity has changed (security, reliability, central management, structure of responsibilities). So why doesn't everyone know this? Well, teachers (and senior leaders, other support staff, etc.) are busy people too - maybe it's just that nobody told them in those terms. However, it's not just on the admin side that things have changed - the uptake of IT within the classroom has evolved dramatically as well. I left school a decade or so ago. I went to a reasonably successful and well-off state school. Yes, we had a cute little RM Connect 2.4 network. What we didn't have was projectors in classrooms; we didn't have any interactive whiteboards; we didn't have a computer in every room; we didn't have electronic registration; no Parental Engagement Portals, no internal e-mail, no digital signage... you get the picture! The technology to support this is changing too. At the school where I work, our previous networks (one for curriculum, one for admin) were powered by three old-school tower servers - Server 2003 and WinXP. Now, it is a fully virtualised environment (VMware) running on HP blade servers - Server 2008 R2 and Win7 - with about a dozen server VMs powering a single-domain network. We run Exchange 2010, SQL 2008 R2, WDS, PARS, Backup Exec, SmoothWall, etc. This is a very far cry from where we were, and a lot of it changed over only a couple of years. We are responsible for managing, maintaining and developing the technological backbone that keeps a modern school running. We are often the only people in the organisation (up to and including the Head) who have responsibility over (i.e. access to) all of its data. Again, in fairness, this isn't how it was a couple of decades ago, but it's how it is now. What do we find, however? Our pay is either stagnating or falling. A Network Manager in my region, however, is paid, on average, about £1K a year less than an NQT at the start of their career. Many of us would like to change this, but it's difficult when Single Status has already taken root in many regions, the resources available to senior leaders to evaluate our skills and competencies are limited and there is no clearly-defined career entry or progression route. Speaking of skills and competencies, IT is a vast field. Software development, database management, networking, system administration, user support, web design... it is possible now to build up an entire career's worth of knowledge and experience in any one of these specialisms. In a school environment, however, you need to know them all. It might only be bits of them all, but schools have certainly been known to encounter problems that would vex a professional with 10 or 20 years' industry experience in their subfield. At the moment, schools hiring IT technicians or Network Managers tend to get a bit of a "mixed bag" as regards their new employee's exact competencies. Furthermore, I don't know of anywhere currently that would advocate or recognise educational IT as an occupation (or sub-branch) in itself. But really, it's a very different breed from working in industry, or in healthcare for that matter. There's a very good post by "ITPROFESSIONAL" on this page that illustrates what I mean here: Help! I want to kill the Network Manager - ICT - TES So, the idea then. I would propose an accredited training course, modular and available at various NVQ levels, specifically tailored to what schools actually need from their IT staff. I'd imagine the foundation might consist of something similar to the following: PC Service and Support Certified Professional (It used to have a Server 2008 module as an elective, which would've been better than the current range I think. I'm sending my apprentice through this accredition over the course of this year.) Added to which could be core and elective modules on things like school support work in general (drawing on e.g. the current "Level 2 Award in Support Work in Schools"), to help technical staff gain a better insight into the needs of teachers and pupils; maybe a module on projector repair and maintenance (I have to admit, I myself know absolutely nothing about this so I have to outsource it); perhaps a module on team leadership for Network Managers; and so on. It is my feeling that the above might generate: * A clearer understanding of our skills --> leading to increased respect filtering down from recruiting officers (i.e. senior leaders) to other staff; * The inception of an entry route into this particular line of work --> leading to tomorrow techie's becoming interested in this work at a Y9 Careers Convention perhaps! * A more concrete feeling of having our own profession with recognised differences from working in industry; * A source for training that is guaranteed to both benefit us and match the needs of our schools, in a way that is very clear and obvious to senior leaders; * An initial reason to define a career and pay progression structure --> leading to better pay in the future. This is the kind of thing that could have been supported by agencies like Becta (abolished), the SSSNB (abolished), BSF (abolished, though that's probably a good thing!) and the TDA (which will die a death on Saturday, to be replaced by an agency that currently seems to show no interest in non-classroom-based support staff). The avenues we could have used to look at achieving something like this are pretty much gone now. What I'd like to do now is approach a couple of training providers - such as QA or Learning Tree - to see whether they might be interested in participating in a venture that has the potential to define the acknowledgement of a new profession. To make it workable and attractive, there would most likely be a need for: * Support from lots of people like us; * Support from a training company; * Support from the government (or perhaps the BCS); * Support from schools. From our point of view, the advantages mentioned above. From the schools' point of view, they're getting staff trained with the specific skills they need - no more "mixed bags"! (I should add at this point that I'm a pretty mixed bag myself, knowing nothing about projectors for example...) From the government's point of view, better-performing technological backbones in UK schools to further improve their results. From the training company's point of view, they would have the monopoly on this, at least initially. I would suggest that they might offer the courses/modules themselves at quite a low fee (to make it affordable for schools), but as the programme became more popular and the standard for IT support work in schools (as there is no other), they would still make a considerable profit from the sheer amount of schools requesting the courses. Perhaps I'm talking out of my backside though. Perhaps much of what's needed is already around elsewhere, though I've not found it. I would welcome comments from anyone - particularly interested to hear the views of @Dos_Box and @GrumbleDook. Any takers?

This is a very helpful solution, but unfortunately it's for a different issue. In our case, the Macs are losing their connection to AD on most, if not all, restarts. You've clearly done a lot of work on this though. What's Deep Freeze then?

That might be a good idea for those still having problems with the script or in general.

There do seem to be mixed reactions here. The script is still working a treat at our site, but perhaps if it's not the same for everyone, or there are still very intermittent issues, then it's a sign of a more deep-rooted problem and/or an issue on multiple fronts. This is something Apple really needs to do something about in my opinion. Our perception was very much that we had bought a product that was thoroughly incapable of its intended use. I'm not aware of this problem occurring on Linux, so it sounds like Messrs Granny Smith REALLY need to take a thorough look at their mDNS code (or whatever else is causing the problem)... mbrunt, that was one of my first throughts, as there are command-line tools to do that. It just gets a bit "messy" on the AD side of things. mbrunt and speckytecky, PM me if you like and we can go through it over the phone? Also, speckytecky, how can you "knowingly forget" something?

Didn't work for us, that's why I wrote the script :/

nano is a text editor. You can use it to create the two files (FixADAuthand StartupParameters.plist) using the contents given above.

I know the script works as it's been copied and pasted directly and success has been reported from other users in this thread: http://www.edugeek.net/forums/mac/43879-snow-leopard-ad-integration-woes.html Please check to ensure you have entered the code 100% accurately.

That's the idea of it, so yeah, I'd should work in that scenario =]

First thing I tried was installing the latest updates, including 10.6.4. Didn't help very much... :/

Certainly markcromwell! You are correct; if you had a local account called Administrator, then the id command would always succeed. I didn't anticipate there being a local account with the same name... I have since come up with an improved method of detecting when the system is ready to accept network logins, rather than just waiting 30 seconds. It seems the Mac OS login window has the ability to display the status of its connection to network login servers, showing either a red or a green light (or orange if you have multiple connections and not all are available yet). If your Mac clients are bound to an Open Directory server (i.e. a Mac server) as well as Active Directory, you can set this option using Workgroup Manager in Preferences > Login Window for individual computer accounts or a group of them. If you don't use Open Directory, you can specify this manually on each client using a command (the last one below). Then you can just tell your users to wait until the light goes green before trying to log in. Now for more detailed instructions for creating the StartupItem, including the modification to the login window: sudo su mkdir /Library/StartupItems/FixADAuth nano /Library/StartupItems/FixADAuth/FixADAuth (enter script from above) nano /Library/StartupItems/FixADAuth/StartupParameters.plist (enter PList from above) chmod 755 /Library/StartupItems/FixADAuth/FixADAuth defaults write /Library/Preferences/com.apple.loginwindow AdminHostInfo DSStatus (not needed if you can set this via OD) Turns out if you're running as root the owner/group permissions will be correct on creation so you don't need to use chown, and only the script itself will need to be chmodded to allow execution.

This is a general post aimed at everyone who has a .local domain and is still frustrated with the Active Directory authentication issue on Snow Leopard, i.e. where at least 50% of the time the Macs will fail to authenticate AD users following a reboot and display "This domain is not responding" in Accounts -> Login Options. I haven't seen any other definitive fixes for this problem yet, so I thought I'd post something that works 100% for us. The problem, as I understand it, comes down to Apple's buggy Multicast DNS Responder implementation (the processes "mDNSResponder" and "mDNSResponderHelper"), whereby .local domains conflict with the Bonjour service and the KDC(s) for the Windows domain can't be resolved, causing authentication to fail. None of the multitude of "fixes" I've seen posted so far have had much success at my workplace, e.g. adding .local to the DNS domain search path, increasing the mdns_timeout value, adding the nameservers / domain controllers to /etc/hosts or setting the AD preferred server to the IP address of a domain controller. As the problem only rears its ugly head when a machine is rebooted (for us), the logical choice for a guaranteed automated fix is to create a StartupItem. Unbinding and rebinding to the domain will fix the problem, but apart from being messy, laborious and causing problems with managed computer preferences mapped to AD computer accounts, which then change, this sometimes fails when automated from the CLI over a period of time, with computer accounts not being successfully recreated and etc. So that's out. Killing the mDNSResponder process is also known to work well, but occasionally fails. Changing any form of DNS setting (to a different value and then back to the old one) will fix it sometimes as well, but neither of these methods work 100% of the time. It therefore seems logical to have our StartupItem shell script use a While Loop to keep repeating the action until the domain is recognised as available again, testing for connectivity in between. Restarting the responder is the most effective option of the two, but killing its process too often (as the Launch Daemon will automatically respawn it) sometimes goes wrong and the process is somehow "permakilled" until reboot - at that point, all DNS resolution goes down the drain and a number of other critical system functions will also begin to fail. This leaves changing a DNS setting. The one I've picked (setting the domain search path to the .local domain in question, which is probably the right setting for most deployments anyway) can be done as many times as you like without causing problems, and while it may typically take over 100 attempts to fix the problem, this normally doesn't last more than about 30 seconds for us. I've just told our users to give the machine around 30 seconds from when it displays the login window before trying it, and they're fine with that. All our Macs now work first time, every time with no problems. To create this StartupItem, create the following directory as root: /Library/StartupItems/FixADAuth Then chown it to root:wheel and chmod it to 755. These must also be the owner/permissions on the two files it will contain, below: Contents of our /Library/StartupItems/FixADAuth/FixADAuth: #!/bin/bash . /etc/rc.common date > /var/log/FixADAuth.log n=0 AuthSuccess=0 while [ $AuthSuccess != 1 ] do id Administrator && AuthSuccess=1 || networksetup -setsearchdomains Ethernet "Empty"; networksetup -setsearchdomains Ethernet middlewich.local; n=$(($n+1)) done echo Authentication successful: $AuthSuccess >> /var/log/FixADAuth.log echo Operation count: $n >> /var/log/FixADAuth.log date >> /var/log/FixADAuth.log Contents of our /Library/StartupItems/FixADAuth/StartupParameters.plist: { Description = "Fixes Active Directory authentication issue"; Uses = ("Disks"); } Obviously you'll need to change "middlewich.local" to your own domain name (and the network interface name if your connection is wireless). The script checks to see if it can see the user "Administrator" on the domain, as he's a fairly common bloke, but if you've renamed yours for security reasons then pick another one. I've also included some logging functionality for debug purposes, so you can verify how well the script is working if you need to and time it in your environment before telling the users how long to wait. The /var/log/FixADAuth.log file will contain the date/time the process started, the success variable set to 1 (just to verify), how many DNS operations were required to fix the problem, and the date/time it ended. For us the time difference is normally about +30-40 seconds with around 120-180 operations taking place. Once you're happy with the script, you can strip it down to its bare functionality if you like, like so for us: #!/bin/bash . /etc/rc.common AuthSuccess=0 while [ $AuthSuccess != 1 ] do id Administrator && AuthSuccess=1 || networksetup -setsearchdomains Ethernet "Empty"; networksetup -setsearchdomains Ethernet middlewich.local done I hope this helps someone! (Yes, I've posted this in two places )

This is a general post aimed at everyone who has a .local domain and is still frustrated with the Active Directory authentication issue on Snow Leopard, i.e. where at least 50% of the time the Macs will fail to authenticate AD users following a reboot and display "This domain is not responding" in Accounts -> Login Options. I haven't seen any other definitive fixes for this problem yet, so I thought I'd post something that works 100% for us. The problem, as I understand it, comes down to Apple's buggy Multicast DNS Responder implementation (the processes "mDNSResponder" and "mDNSResponderHelper"), whereby .local domains conflict with the Bonjour service and the KDC(s) for the Windows domain can't be resolved, causing authentication to fail. None of the multitude of "fixes" I've seen posted so far have had much success at my workplace, e.g. adding .local to the DNS domain search path, increasing the mdns_timeout value, adding the nameservers / domain controllers to /etc/hosts or setting the AD preferred server to the IP address of a domain controller. As the problem only rears its ugly head when a machine is rebooted (for us), the logical choice for a guaranteed automated fix is to create a StartupItem. Unbinding and rebinding to the domain will fix the problem, but apart from being messy, laborious and causing problems with managed computer preferences mapped to AD computer accounts, which then change, this sometimes fails when automated from the CLI over a period of time, with computer accounts not being successfully recreated and etc. So that's out. Killing the mDNSResponder process is also known to work well, but occasionally fails. Changing any form of DNS setting (to a different value and then back to the old one) will fix it sometimes as well, but neither of these methods work 100% of the time. It therefore seems logical to have our StartupItem shell script use a While Loop to keep repeating the action until the domain is recognised as available again, testing for connectivity in between. Restarting the responder is the most effective option of the two, but killing its process too often (as the Launch Daemon will automatically respawn it) sometimes goes wrong and the process is somehow "permakilled" until reboot - at that point, all DNS resolution goes down the drain and a number of other critical system functions will also begin to fail. This leaves changing a DNS setting. The one I've picked (setting the domain search path to the .local domain in question, which is probably the right setting for most deployments anyway) can be done as many times as you like without causing problems, and while it may typically take over 100 attempts to fix the problem, this normally doesn't last more than about 30 seconds for us. I've just told our users to give the machine around 30 seconds from when it displays the login window before trying it, and they're fine with that. All our Macs now work first time, every time with no problems. To create this StartupItem, create the following directory as root: /Library/StartupItems/FixADAuth Then chown it to root:wheel and chmod it to 755. These must also be the owner/permissions on the two files it will contain, below: Contents of our /Library/StartupItems/FixADAuth/FixADAuth: #!/bin/bash . /etc/rc.common date > /var/log/FixADAuth.log n=0 AuthSuccess=0 while [ $AuthSuccess != 1 ] do id Administrator && AuthSuccess=1 || networksetup -setsearchdomains Ethernet "Empty"; networksetup -setsearchdomains Ethernet middlewich.local; n=$(($n+1)) done echo Authentication successful: $AuthSuccess >> /var/log/FixADAuth.log echo Operation count: $n >> /var/log/FixADAuth.log date >> /var/log/FixADAuth.log Contents of our /Library/StartupItems/FixADAuth/StartupParameters.plist: { Description = "Fixes Active Directory authentication issue"; Uses = ("Disks"); } Obviously you'll need to change "middlewich.local" to your own domain name (and the network interface name if your connection is wireless). The script checks to see if it can see the user "Administrator" on the domain, as he's a fairly common bloke, but if you've renamed yours for security reasons then pick another one. I've also included some logging functionality for debug purposes, so you can verify how well the script is working if you need to and time it in your environment before telling the users how long to wait. The /var/log/FixADAuth.log file will contain the date/time the process started, the success variable set to 1 (just to verify), how many DNS operations were required to fix the problem, and the date/time it ended. For us the time difference is normally about +30-40 seconds with around 120-180 operations taking place. Once you're happy with the script, you can strip it down to its bare functionality if you like, like so for us: #!/bin/bash . /etc/rc.common AuthSuccess=0 while [ $AuthSuccess != 1 ] do id Administrator && AuthSuccess=1 || networksetup -setsearchdomains Ethernet "Empty"; networksetup -setsearchdomains Ethernet middlewich.local done I hope this helps someone!

This problem is fixed now. Group Policy was preventing users from accessing 16-bit applications. It would appear that while this programme is a new (and officially 32-bit) version of the old DOS-based incarnation, it still has some 16-bit components lying around somewhere...