PiqueABoo

I'm never sure what this kind of thing tells us, especially when one of the "databases" concerned was selected for stupidity i.e. people who fell for a phishing attack. My passwords tend to reflect the value of what they are protecting so I never use clever ones for signing on to web-sites (like here for instance), and anecdotally I've come across quite a few people who do the same. Experience says a lot of people really do use some terrible passwords for important data though.

I'm not like to do this in the near future sorry, but that would take ~ 50 lines of a dotNet forms app. Read a couple of registry (policy key) settings to tell you which OU(s) and maybe which group(s) you delegated the AD rights to, an AD check of whatever account name the user types in, and then password reset itself - a perfect little project for someone who has done the beginner stuff and now wants to tackle something a bit more useful.

It can be very relevant e.g. I use on the parent folders for user profiles and home folders (the user folders under there are created by the OS at first logon) Folder permissions tell the OS what permission to put on files and folders created within it. If it were Creator-owner:Modify, then when Alice creates a file in the folder that file will get given Alice:Modify rights. Bob would get Bob:Modify on files he creates and so on... You might do something like this in a shared folder: Creator-owner:Modify, Everyone:Read. I could then put some lovingly written document in there, everyone could read it but they wouldn't be able to edit it and mess it up - I'm the only one allowed to mess it up! It can get more complex than that in RL, but this is the basic concept.

I would definitely advise against that. Sorry, but given the ease of resetting a broken profile and moving on I've never bothered to stop and figure out a solid technical case for why it can hurt, but I'm pretty sure it has caused some hurt. Perhaps there is some alternative: Why do teachers need these multiple logons?

Alas, that seems to be a common story. Can't really explain it but it strikes me as an odd area... lots and lots of references out there but very few are useful, and even fewer of those are technically interesting e.g. some cool, cunning and helpful thing you might do with an arcane Cmdlet or two. That codeplex link points to projects with relatively small download figures. You wrote that remarkably posh doc on ILM etc. didn't you? Did you pause to wonder why there weren't lots of guides like that kicking around out there already? Or that the only reasonably comprehensive L@E implementation guide appears to be the MS UK one which only appeared at the start of the year? How long is it that Live@du been going now? Perhaps the message is that cloud computing will be cloudy: a bit dull, grey and opaque. Suspect some of it is because of the MS "partner" thing (I have never tripped up over that word so often and I once sorted that status out for an employer), and it seems a lot people are firing and forgetting: I bet almost everyone with a local Exchange knows what retention time they have for their user's deleted mail, but no answer yet for my question about that for users set up on Live@edu? Will that LEA not allow/configure incoming HTTPS access to OWA on the Exchange server? The one here will. Keep it simple. Having an Exchange to begin with, never mind Exchange and Live@Edu doing shared address space seems like serious overkill for a Primary.

Outlook 2007: Just worked as expected. Well nearly... there was a proxy to get through, the initial autodiscovery ignored IE's proxy so I set WinHTTP one to make it happy.

Staff = non-student so they get them then? Banner advert = web i/f. Presumably ads won't be patched onto the end of e-mails so if they use Outlook they won't notice? Interesting so in principle you could have: -Staff and older student can send anywhere -Younger students restricted to say "sch.uk". Would the latter match "[email protected]" or only "[email protected]"? Definitely not Outlook 2003 on the one I've got my hands on (not sure if this is a regular test account or not). IMAP4 doesn't count, as in why would you bother to run Outlook for a severely cut down mailbox feature set? I was trying to avoid hearing about really arcane/specialist requirements that just aren't useful to most of us. Let's put it another way - why do some organisations apparently choose to put students on Live@Edu, but staff on a different mail system? I've seen a few state they do that (but not why), and of course there's the "Shared Address Space" scenarios to make it easy to do that with a single mail domain used by both. -- Which is a very, very significant plus. I'm trying to do myself out of a very occasional job commissioning Exchanges. That doesn't bother me because although they tend to just work, the support for the management side of things (with folk who needed me to set it up) can be somewhat frustrating. --- So what kind of reliability are we looking at? Have there been any unplanned outages say in the last year and how long?

Guess whose star-sign is Taurus then? Via some output obtained earlier today from an Outlook Anywhere (RPC over HTTP) test with the Exchange connectivity tester I just configured an O2K3 profile to connect and it said: "Your Exchange server administrator has blocked the version of Outlook that you are using. Contact your administrator for assistance" I then used the remote powershell stuff to check the value of MAPIBlockOutlookVersions for mailbox "plans" (eek - all this lovely new jargon!) and it's empty which strongly suggests it is a "per server" restriction. All of which seems fairly conclusive.. which after trawling through lots of fuzzy stuff, this is *good* even when it's not the outcome I wanted. But since the above connectivity test did make it all the way to the mailbox store I imagine O2K7 & O2K10 Anywhere will be OK, but I don't have one of those to hand right now so I'll save it for another day. PS: Having just typed all that in carefully for the potential benefit of future budget-challenged edu-folk, I checked my mail and found an MS response (I'd asked them too) which makes it very conclusive: O2K3 MAPI isn't supported - apparently there's no public store to keep it happy on Live@Edu.. which is essentially the same story as Exchange 2007 when you say no to the installation question "Do you have any client computers running Outlook 2003.."

Struggled to know where to post but I guess here will do. Only just found this and it is *very* useful for those occasions umm.. when it would be *very* useful(!) : https://www.testexchangeconnectivity.com

Prompted by another thread I'm currently trying to (reliably) understand what you can and can't do using Outlook to talk to your Live@Edu account. It looks like O2K7 & O2K10 can just use AutoDiscovery to just set itself up and that will probably work, but I'm still stuck working on O2K3 which unfortunately won't entirely disappear completely from my world for a while yet. Some of the Uni etc. user guides kicking around for this say no to O2K3, others have you configure IMAP. Just seeing that distinction makes me think the former are wimps because IMAP must be do-able. Has anyone here stubbornly pushed this - O2K3 does do RPC/HTTPS so I'd have thought there is at least a faint chance you could make it happen, but the problem then would be using fixed server details as opposed to potentially dynamic ones from AutoDiscover. [Alternatively, has anyone seen a succinct doc that is definitely about Live@Edu as opposed to standard windows live, that tells you which clients can do what right now?]

Anyone care to suggest a domain registration outfit that also hosts and provides management of the DNS zone (for more than just "www.example.com" and a single MX)? The obvious key point is one where that tends to just work, they don't charge you £££ to move it elsewhere, don't annoy you a lot...

Disclaimer: It's been quite a while and I'm not 100% clear what they want to achieve but there are two typical scenarios in trusts: Potentially Easy: domainA\Fred logs on to domainA computer and accesses resources in both domains. Potentially Hard: domainA\Fred logs on to domainB computer and accesses resources in both domains. For the hard one you have to worry about what User policy Fred gets to do all that desktop lockdown we all have. They're not in domainB's active directory where domainB's user policy is linked so won't get any when logging on there without some effort. The default trick used to be to pick up all the policy that applies to average domainB user and link it to domainB computers, and with a forest trust the system automagically applies that linked policy to Fred via loopback processing. You also have to add more loopback policy to add extra drive mappings etc. to resources back in domainA. This might just work if you're lucky when domainB is a CC3 (or for that matter any other seriously developed vanilla that never expected to have to accomodate this) but I'd expect a bit of a battle I might not win. In this specific scenario I'm much happier contemplating making the trust, but Fred has accounts in both domains i.e. you add mappings back to domainA when they log on to domainB as domainB\Fred account. But I wouldn't want to do that either - doing this kind of thing between separately managed organisations often gets bogged down in politics and then thrown away after a while. If it's between new or revamped vanillas that's different and approaches like willtech's might be viable, but I can't see that ever working with a CC3 and vanilla. It can all get a bit hideous really and AIUI peripatetic students are one of the very significant factors in RBC/whatever VLEs [will they survive given the Incredible Disappearing HT Grants] and other keep-your-stuff-in-the-sky campaigns i.e. so it's all there in a familiar guise wherever you are. PS:"domain' really means single-domain-forest in the above.

Don't take this as the final word by any means, but CC3 may inadvertently get in the way and I suspect most of the problems will be for Vanilla folk trying to logon to workstations in the CC3 school. No domain drop-down on the logon screen for starters, and although I think you can put the MS Gina back I suspect the issues won't stop there. The Group Policy RM have abstracted away behind their management console is one of the potentially "interesting" bits (what User policy does Vanilla user get on a CC3 workstation and vice versa?)

Yes please. I really, really ought to get my head around this and I will read that long MS UK implementation guide I just found.. eventually.. but a few potentially simple feature questions about the e-mail side: a) Skimming some MS FAQ somewhere it blathers on about Students, Staff and Alumni and there's stuff about whether various categories do or don't get (sanitised) tips and advertisements etc. What is that all about then? If you put a bunch of Students on it what do they get? If you put a bunch of Staff on it what do they get? b) Does delegation work i.e. so person A can be given rights to read mail for and send-on-behalf of person B *without* having to logoff and log on as person B? c) Can you point normal Outlook at it? d) Can you point Active Syncing gadgets at it? e) Does it have deleted item/mailbox retention? If so for how long and can you make it longer? f) Is it possible to restrict the domains students can send to? If so would that be all students or could you restrict particular [year] groups of students? g) Suppose I might have already hit some, but given that it's free what *realistic* missing features would make someone discount Live@Edu and get a local Exchange instead? [ignore the obvious account provisioning, password syncing and anything really arcane that hardly anyone uses on Exchange.]

For some reason most of these seem to be stuck in the genuine DOS world so I ended up writing my own util to get a job done. Lots of them would do ASCII (one byte per character) replaces, but I didn't find one that would also play nicely with the Unicode varieties e.g. some of those increasingly ubiquitous XML config files you might want to patch. IIRC I found something like eight different format varieties of what are superficially "text files".

The obvious issue is that Microsoft and presumably RM stop supporting 2003 in less than five years time. Obviously this only matters if you think you ought to be able to string a server out for at least the next five years (that's probably more important for smaller sites with smaller budgets). Other than that I can't see what 2K8R2 CC4 will do because I can't see RM wanting to make it significantly inconsistent with 2K3R2 CC4. I think RM just had unfortunate timing. There's not much you can do with CCx that I can't do with 2K8 native (and the associated deployment tools etc.). So if CC4 had coincided with (was targeted for 2K8) then in principle RM could have gotten away with a lot less code and subsequent bug-fixing. But I suppose they may have insisted on writing all their own stuff anyway.

Can't say I recall "freedom" being used in anything much besides marketing for a long while (too cheesy for anything else). That too. So Spannerman2, what's the day job then? Ex-teacher working for some org that makes it's money from consultancy/mangelment/services based around open source? Or am I way out?

So what's your strategy for making code that plays nicely in both 32bit & 64bit environments? I didn't have one, but then it turned out I had Microsoft's all along: For the last couple of years I've largely written dotNet targeted at version 2.0 unless I really need higher, using VSE running on XP (32bit) and there is no choice but to have your code built for "Any CPU". So on 32bit an app runs as 32 bit and on 64bit it runs as 64bit. If you happen to write/read the registry it's always in the same path on both architectures - no Wow6432Node magic involved. I did however, run into a little pain (pinprick) with a compiled AutoIT app which ultimately calls a couple of CMD files, and being 32bit that runs them with the 32bit cmd.exe so any reg settings and so on you do there automagically end up redirected into that Wow6432Node. I also had one of those CMD files install a INF file, and the standard variable %11% in there which would point to system32 on a 32bit system ends up pointed at SysWOW64. [1] Thinking about all this I still really hate the couterintuitive side of 64bit Windows i.e. the system32 folder is where the 64bit code lives and the SysWOW64 folder is where the 32bit code lives [1] I did something completely different in this case, but you can do some workarounds like this. if exist %systemroot%\sysnative\reg.exe (set reg="%systemroot%\sysnative\reg.exe") else (set reg=reg) %reg% add blah blah...

Thanks, that *is* better, as in at least I can see a treeview for the UNC now (no amount of clicking and expanding would get it for me before). Alas it uses an existing Window rather than making a new one and slowly/erratically shuffles my UNC tree out of view as it starts filling up the Network bit immediately above with the local browse list. I can't make that happen on the system I have to hand so I'm perplexed too, but it has definitely been plaguing me elsewhere. The symptom is when you vertically scroll a treeview which has lots of sub-folders showing in a typically not very-wide pane , it keeps moving the tree left and right, presumably to keep what it thinks I'm interested in visible. Could well be some setting certain other folk have set for no obviously good reason, I suppose.

My theory is that MS just needed any sufficiently different UI for Win7 to bolt on top of not-that-different-to-Vista-behind the scenes as opposed to a good UI, and between their marketing and quadrillion pet-bloggers everything would be fine (and they were right). It's ten times more annoying on Server 2K8R2 when you're trying your very best to to do things efficiently, but have to wade past inappropriate-for-servers features designed to keep dim-witted home users happy. I won't enumerate these coz I'll be here til Tuesday, but this is my current bete noir: In pre R2/Win7 Explorer I get some significant mileage out of this: explorer /e,/root,\\somecomputer\c$ If you've got an ancient Windows to hand (and can access c$) you can see the effect by running this: explorer /e,/root,\\127.0.0.1\c$ You might guess that I'm clicking a computer context menu to kick that off. But try it on 2K8R2 and you get the right-hand pane OK, but the tree in the left stays stubbornly stuck in it's Favourites, Libraries(!), Computer, Network groove and that is just really annoying not least because the not-brilliant workaround probably involves mapping a drive letter. Oh and 2008 [R2] Explorer Search still bugs me quite a lot too. So.. does anyone know if there are any alternative Explorers that a) You have used lots so you know it isn't full of bugs, b) Haven't caught Featuritis, c) Will do the equivalent of what /e,/,root used to do? PS: d) Doesn't have a tree-view with an unhelpful derranged mind of it's own when you scroll it up and down.

That would work if it pings, otherwise you normally get a Windows event log entry which has the MAC in it (in the log on the system that is complaining about the conflict). I usually look up the vendor the MAC belongs to in the IEEE OUI because that can sometimes help tell you what device wotdunnit.

Seconded. When I've had sufficient control of DNS I've always done that e.g. 24 hours => 20 min TTLs a couple of days prior to significant IP address changes and it's always been worthwhile. Hasn't always done what it was supposed to everywhere because of some "interesting" configs out there on the net, but it certainly tends to help.

AIUI: Unless you are clustering on member servers/workstations all the SQL groups are local groups. You only get domain groups on a DC because the SQL install has no other options i.e. it can't make & use local groups on a domain controller. I've only got an Express to hand used for something else, but that is the same local groups & members as you listed plus: SQLServer2005SQLBrowserUser$SERVER_NAME NT AUTHORITY\LOCAL SERVICE SQLServerFDHostUser$SERVER_NAME$INSTANCE_NAME SQLServerReportServerUser$SERVER_NAME$MSRS10.INSTANCE_NAME NT AUTHORITY\SYSTEM

You'll probably never need to know this but.. I wanted to (programmatically) create a local Win service account with a set & forget random password, and when I got to the random bit just cut & pasted a function I once very carefully made for something else which happens to spit out 256 cryptographically random bits i.e. 32 bytes. But passwords need to be strings, not bytes so I just quickly converted those 32 bytes to a 64 character hex string to use as the password. But my test Server 2008 R2 doesn't like that because although a string made from a limited character set (16 chars total) representing 256 random bits is MUCH more respectable than any password any typical human is likely to make[1], it's not "complex". [How I wish Windows complexity checking would factor in length i.e. go "Ooh look! It's a 30 character password... hmmm.. LANMAN is definitely not happening here so I'll relax some of the pedantic nit-picking rules because they're obviously pointless in these circumstances".] So next I thought I'd just quickly throw some stuff on the front of the password string to keep [bleeping] Windows happy e.g. "Xa91£$" + . But my test Server 2008, or at least the function I invoked doesn't like that much because despite my added "complex" stuff the password apparently still doesn't meet the complexity requirements! So then I expermientally tried "Xa91£$" + <32 of the original hex chars> and it just worked. So I assume the API was really complaining about the password being too long, but perhaps no one ever got around to making a system error code for that. Browse the net and you can find some anecdotal comments about the max password length being ~128 chars, but perhaps that is 128 bytes because (ignoring length and other gubbins) being Unicode, my 64 character hex string needs 128 bytes of storage. So again, you'll likely never need to know this, but password strings longer than 64 characters can cause trouble in at least one Windows API. [1] Equivalent to a 40 character password utilising a scattering of chars from the full ASCII char set.

Go to device manager where you have the driver happily installed etc, right click the relevant NIC -> Properties -> Details and you get a line like this: PCI\VEN_8086&DEV_1029&SUBSYS_01... You will have different numbers, but in this example: VEN = Vendor ID = 8086 (cutely based on Intel's old CPU name) DEV= Device ID = 1029 The next bit after the semi-colon is the driver name in RM land - IIRC what you called it when you imported it.