ajbritton

I've had two problems connecting to WiFi lately which I'll pass on just in case; 1 - I did what Sted suggested and accidentally disabled WiFi using the hotkey which is next to the hibernate key which I use all the time. There was no indication apart from the fact that I couldn't connect. 2 - Time on my router was out of sync with laptop. I had to connect over a LAN connection and update the time on the router which was more than an hour out. This sorted out the problem. Presumably you are using WPA and have entered the correct key?

Hmmm You've described a technical solution to something, but what is the actual problem you are trying to solve?

I've often thought about writing something similar myself. Here's a few things that I've considered for inclusion (in no particular order) ... 1 - Should support acknowledgement of message. 2 - Statistics - For each message sent, it should be possible to gather statistics on where it was displayed and acknowledged. This will help measure its effectiveness. 3 - Should support targeted by group messages (e.g. Everyone, Staff, Students) 4 - Should support hyperlinks to take user to more detailed information 5 - Should support 'silent' mode so as not to interrupt presentations. Perhaps it's possible to detect an app running full screen? It should also be possible to override this for super-critical messages. 6 - Command line interface so that automated messages can be sent 7 - Should not seize focus as this would interrupt the user 8 - Should support targeted messages by user environment (e.g. target thin client sessions only) 9 - Should not rely in having a presence in the tray although could still support it 10 - Should have low memory/cpu footprint to minimize impact on thin client I was thinking of using AutoIt to develop this but am not happy with the memory footprint.

Also, bear in mind that the security context that a Startup Script runs in means that it only has Anonymous access to network resources. If the script is installing software from a server share that only has 'Authenticated Users: Read' for example, it will not work. If you allow 'Everyone: Read' (share and file level permissions), then this should do the trick. Even then, this will only work on servers in the same (or trusted) forest. I came across this problem when trying to automate SIMS installations onto PCs in a 'Curriculum' domain that was in a different forest to the 'Admin' domain where the installation files were stored. Solution in the end was to replicate installation files to a server on the 'Curric' domain. Yuck.

A new comment on Marks original article has appeared that explains what I've been trying to, but does a much better job. Mark's Blog : The Machine SID Duplication Myth Comment dated Saturday, November 14, 2009 5:08 PM by Steve Gray

If you just wanted to securely erase certain files, you you could try Eraser (Eraser). Assuming you succcesfully targeted all the sensitive files, this might be quicker. This would also have the benefit of not wiping out the OS! Depending on how paranoid you are, though, you might worry about other sensitive files that you forgot or temporary files. If I was selling a PC, even to someone I trusted, I would still want to wipe the disk. Once the PC is out of your hands you've no control over who might get hold of the hard drive in the future. Speaking of the OS, assuming it was an OEM installed copy, then the license will be locked to the PC so would need to be sold with the computer. If it's not an OEM copy and you are transferring it to another computer, then it will need wiping from the old PC so a disk wipe would be the best bet. DBAN has a number of different levels of secure wipe. The default settings should be good enough for most people. It's still a bit slow, depending on the size of the hard drive, but does the job properley.

One point worth noting is that a cached logon by user X on computer Y can only take place if user X has logged on to computer Y whilst it was connected to the domain, first. This is so that computer Y can record the logon details of user X and recognise them when it is not connected to the domain! It's common sense but can be overlooked occasionally!

Another vote for Darik's Boot & Nuke (DBAN)

That's an excellent question that I'm afraid I can't answer. Have you tried posting on the AutoIt forums? Not surprisingly, there are many AutoIt gurus there.

IMHO, best practise is as per Tom_Newton's post. Each users gets a 'standard' account which can be used to log on to the domain and do basic working tasks (Office, Email, Internet etc). Any users who perform 'admin' tasks should have an additional user account, also unique to them which is used just these purposes. This follows the principles of least privilege. Users needing to do 'admin' tasks either log on to a PC with their admin account or (as I do) use RunAs to run an Admin tool with elevated privileges. The Admin account should also only have the essential permissions. For example, my own 'admin' account has not access to Internet or Email as this would duplicate what I can already do with my normal account. This way of working is initially burdensome to those used to logging on as a Domain Admin all the time but it's surprising how quickly you get used to it.

If the installer will run to completion on a 2003 server, you could do an 'admin' install (SETUP.EXE /A) which will basically extract all the files to a folder that you designate. You can then install workstations from the files that have been extracted.

I don't think so. Where do the invites appear?

NB - This process relates to local user accounts. Indeed, but this process happens at the remote machine (by the file server process as Mark refers to it) that the connection is being made to, so when connecting from machine A to machine B... Machine A sends an SMB request to machine B. This includes the username/password. It would be pointless sending a SID as only machine A would know anything about it. Machine B authenticates the username/password either against the domain or the local user account database. At this point a 'logon session' is created on Machine B holding the access token that will be used to access the resource on Machine B. A UID pointer is returned to Machine A Machine A stores the UID in the open SMB request for Machine B. When a request to access a secured resource goes from Machine A to Machine B, the open SMB channel is used along with the UID that Machine B then uses to refer to the original logon session created during authentication. The point is that the SID does not travel from source PC to destination PC. The only place the Machine A SID has any relevance is on the Machine A and the same applies for the Machine B SID. (apologies for multiple edits but I'm just coming to terms with this stuff myself)

Not quite. Windows does not need to 'tell them apart' as such. A remote connection will be authenticated by username/password and as long as these match a local user account on the target PC then the connection will succeed. This is nothing to do with machine SIDs. The only time Windows would confuse two accounts based on matching machine SIDs would be in the instance where an ACL was created on a removable device and the device was connected to a second PC with the same machine SID. The second PC would see entries in the ACL as referring to local accounts rather than accounts on a different PC.

Software Restriction Policy Here's the setup I used. Obviously students are set as limited users only. The LNK extension has been removed from the Computer and User default SRP policies so that items on the start menu/desktop can be launched. There are other ways to achieve this, but this seemed easiest for my setup. I do not use redirected start menus/desktops for students. Students get a mandatory profile but to not see the 'all users' desktop/start menu by default. Instead a logon script copies approved items from the all users desktop/start menu into the student desktop/menus at every logon. Computer Policy (for all computers that students will use) - Default SRP policy - Remove LNK from the list of designated file types User Policy (for all students) - Default SRP policy - Enforcement: Apply SRP to: All software files except libraries (such as DLLs) - Enforcement: Apply SRP to the following users: All users except local admins - Designated file types: Remove LNK - Default security level: Disallowed Default Path Rules - %HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\SystemRoot%: Unrestricted - %HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\SystemRoot%*.exe: Unrestricted - %HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\SystemRoot%System32\*.exe: Unrestricted - %HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ProgramFilesDir% : Unrestricted Custom Path Rules (NB - The students only have read access to these locations) - \\(servername)\apps: Unrestricted (networked applications / ISO images) - \\(servername)\install: Unrestricted (managed software MSIs etc) - \\(servername)\public: Unrestricted (public area) - \\(servername)\sysvol: Unrestricted (required for logon) - \\(DNS domain name)\sysvol: Unrestricted (required for logon) - C:\OLDAPPS: Unrestricted (Any PC apps which don't like running from C:\Program Files are installed under OLDAPPS. Again, students only have read access to this folder by default. If you have any naughty applications that need write access to their program folder (under C:\Program Files or C:\OLDAPPS), then permissions can be altered as required and an additional path rule added to prevent execution from that folder. It is possible to use environment variables (eg %USERPROFILE%) in path rules, but avoid this as the value of an environment variable can sometimes be modified by the user. This was my first time with SRP, so I don't claim this list to be definitive in any way!! It seemed to work OK for me though.

Try the following search; with:public then try with:public edugeek and join in!

Anyone interested in Google Wave may like to keep an eye on Gina Trapani's site; Smarterware.org. Gina is a developer and self confessed Google Wave addict. She has just published a book 'The Complete Guide to Google Wave' (available online: http://completewaveguide.com/) and you can hear her talking about it with Leo Laporte and Jeff Jarvis on 'This Week In Google' (The TWiT Netcast Network with Leo Laporte). You can follow her on Twitter of course (@ginatrapani) and especially her Wave related content (@gwaveguide).

You can change your user pic in your Google Profile (http://www.google.com/profiles)

Surely that's because you're either logged on as a Domain Admin (and therefore have local Admin rights on all Domain joined machines) or are using a local account which exists on all PCs and has the same password.

It's worth reading through the comments. Several people make the point that although Windows may not rely on having unique machine SIDs, there is other software that does.

Just picked up my invite this morning. Many thanks Arthur. If I get any invites to offer, I will post here.

Surely user would need to be local Admin on the PC to add it to domain. The way I understood this setup was that although user is allowed to add a computer to the domain, the computer account would have to already have been created. Has anyone actually tested this?

PM sent. Thanks

Hasta la Vista Baby (sorry!)

"It's here, it's awkward and you will have to use it eventually, so let us make the mistakes so you don't have to." Surely time to update this...