powdarrmonkey

Because you assume that exam boards are competent and proactive, and want to help their customers.

I'm not writing it for you, if that's what you mean... Let me google that for you

Request -> external provider:443 -> your box:someport Response -> your box:someport -> external provider:443 -> destination where traffic between you and your provider is protected by a self-signed, and between them and the client over a properly-named one.

Can your external provider host a reverse proxy for you over a self-signed certificate, then re-certify it to send to the destination?

You cannot in your current setup, because DNS (quite rightly) doesn't know about ports, protocols or URIs - only names. You'll have to change your internal hosting to a standard port or live with having https://sub.domain.co.uk:Port as your address (why the port, anyway? this is what IANA's well-known ports are for).

That's not Shutdowertron's fault. Run gpupdate /force /boot at a prompt.

Nor did I. I'm just surprised to see a school so keen on freedom publishing documents with advice that they "require" proprietary software to open them.

And yet publish documents that "require" Adobe Acrobat. Interesting... Can you expand on the details given in them? Particularly, why two VLEs?

Yes. The whole point of Shutdownertron is the agent on the client does the work, so if network connectivity is lost or the server goes away the payload is still executed. It's an MSI so that you can deploy it silently with your normal tools, whatever they may be.

And during the transition, duplicate addresses will be allocated. This is an unsafe approach.

I would not. My approach would be to create a new DHCP server and allocate a new range to it, and allow both to work in redundant parallel for a while. Then you gradually reduce the range available to the original server so that clients transition off it onto the new one - eventually all of them, and then you can decommission the old server and increase the address space available to the new one. You have to do this over a period of several (my rule is 20) N, where N is your lease time. If you just pull the carpet out from under one server, you leave clients thinking they have leases while in fact the new server is allocating the same addresses to someone else, and you get ugly collisions.

It's more or less the same. Tell IIS that you want to renew it, let it generate a CSR and send that off for signing. The only difference in a renewal is that you don't generate a new key first.

I'd like to clarify a myth here: keeping your main database and log files on different physical disks is nothing to do with performance; it's for safety should a disk fail and you need to recreate one or the other. edit: that is not that performance can't be increased by separating them, just that you probably won't notice one way or the other.

LNL - Free Printers For Schools

Our deployment of Studywiz can do all this (we don't use SSO, but I believe it can do it...)

awesome! rep++

Wrap it in [ code ] tags (collapse those spaces). Everything would be far easier to read if you used a proper templating engine, like smarty...

1. Do a custom install and unselect the 'Shutdownertron Service' component, and select the 'Group Policy Templates' component 2. Don't apply your shutdown policy to servers

No. How about a little user education?

Possibly, though it's yet to happen.

Yes, though there are about 1000 of us, so I don't really stand out (plus a further uncountable number of contributors, translators, documentation writers, DSA, etc). Debian is a do-ocracy: if you think it ought to happen, you get on with it. There is a process for becoming a developer, but newbies can work through a sponsor until they decide if they want to commit.

We plan to release Debian 6.0 "Squeeze" before the year is out, if it's ready, so you'll find Lenny is looking outdated already... if you want to try effectively an RC version, use the testing suite, which is frozen and being manually assembled right now. (How Debian suites work.)

Nothing, I hope. Recent versions of X (and consequently Ubuntu releases) have been xorg.conf-less.

I avoided weighing into this discussion earlier, but hey ho... ATI has historically been a Really Big Problem™ because they don't release open drivers, they insist on dumping binary blobs - or, recently, making you build a kernel module yourself, to which the unprepared user just goes 'huh?'. Nvidia have a mixed history, but in their favour they are considerably more open about how their stuff actually works, so the reverse-engineering effort has been much more successful. New cards always take a while to gain support though, so if you really want compatibility check it before buying - IIRC, the Xorg folk have a list of good chipsets.

Brief history lesson: Debian Founded: 1993 Type: all volunteer community Release approach: when it's ready (as few RC bugs as possible) Focus: freedom Learning curve: perceived as steep Strengths: very stable, very predictable, very competent package maintainers, decisions taken by whole project, long term support Weaknesses: packages can lag behind upstreams because testing is very thorough Ubuntu Derived from: Debian, with appropriate modifications First release: 2006 Type: commercial, with strong community Release approach: every 6 months Focus: world domination (by sacrificing some free principles) Learning curve: perceived as easier, but much more hear-say to learn to avoid Strengths: up to date software, wide user base, commercial support available, long term support, lots of money for interface research Weaknesses: wider community can result in lower skill set in packaging and weird or bad decisions (like the python debacle), project decisions guided by Canonical Ltd Mint Derived from: Ubuntu normally, but they decided it was too unstable and next release will be Debian 6.0-based First release: 2006 Type: (small) volunteer community Release approach: when it's ready after a Ubuntu release Focus: eye candy and usability Learning curve: similar to Ubuntu Strengths: pretty, derived from somewhere sensible even if it's a grandfather, ease of installation, up to date software Weaknesses: small developer base, derived from a derived project, upgrade path is awkward