ajbritton

I'm asking Santa for a mouse to go with my laptop. I'm torn between a wired/wireless design. I use the laptop at home just on the batteries quite a lot, so the idea of having to plug in a mouse seems just plain wrong. Having said that, there are some clever wired mice with retractable USB leads (example). Additionally, the USB ports on the laptop are on the left hand side and I'm right handed. Any advice on this one?

@Geoff: Don't believe your eyes. I know what you mean, that when you are logged on to a PC and look at the properties of a network connected printer, the ports shown are exactly the same as you would see if you were at the server. You will see the same thing though for printers which are directly connected to the server, or via any other remote print server. Windows certainly doesn't shortcut the connection to other remote print devices, so I see no reason why it should do so in this case. One way to prove this would be to firewall the PC hosting the printer and only allow incoming connections from the server hosting the print queue.

You could route all your printing via a server as follows; 1 - Share the printer on the PC (eg \\PC01\printer1) 2 - Create a new port on the server (\\PC01\printer1) 3 - Install a new 'local' printer on the server attached to port \\PC01\printer1 4 - Share the new printer on the server \\server\printer1 5 - Connect clients to the printer on the server Print jobs will all route via the queue on the server. This way it will only be the server sending jobs out to PC01 (gets around the max 10 connections limit).

@NetworkGeezer Certainly didn't feel any digging going on! I thought you were saying that the script would only be useful against machines which were already on AD with given names. I posted the script in response to the original post which was asking for a way of getting at the UUID. In response to your question about doing 'server side renaming'. To my knowledge it is not possible. You can use Netdom, and provided the PC is switched on and not firewalled, then it can be done remotely.

As for dual booting, I can see the use for Power Users, but I think for general users, virtualization gives performance which is more than adequate. I've not actually tried VPC on a Core 2 Duo equipped machine, but I have run Virtual Server 2005 on a Dell 2900 server with super dooper dual core xeons, and a virtual XP machine was at least as fast as most of the P4 based classroom PCs.

I've also looked briefly at SVS. The basic freebie kit comes with a primitive repackager type application that attempts to capture the changes made to your PC when you install a piece of software. As DB says, it's fine for small or simple apps, but when start using more complexe apps (which don't always submit well to conventional repackaging anywat), then the learning curve becomes more like a learning wall. SVS is alive and well though. The current version of Wise Package Studio (7.x) supports repackaging to a virtual software layer. I've not tried it though.

First of all, are you using roaming/mandatory profiles or just local profiles? This page will give you the syntax for the various parameters. I always run Delprof from a Startup script which ensures nobody is logged on (except System I suppose) when it runs.

You can use the script on any PC, it does not need to be on the network. Obviously though, a new PC would need to go through the tedious XP setup screens before you could run the script. The other possibility is to boot using BartPE. I believe there is a plug-in that lets you run VBScript. I don't know if WMI calls would work however. Some useful Microsoft RIS stuff (including script to get UUID) here

Another thought; Assuming temporary profiles are based on the local Default User profile, then all you need to do is create a locked down profile and distribute it to all PCs (eg using Startup script). No point it making it mandatory as temporary profiles will be deleted at logoff. You could set the desktop to be bright red to make it very obvious to teaching staff what is going on.

@ICTNUT: Any reason why my idea of a locally cached mandatory profile would be no good for you? Maybe you're using individual roaming profiles?

@NetworkGeezer: The script extracts the UUID from the PC on which it is run. The name of the computer is not relevant. If you happen to have bought Dell OptiPlex PCs, then the UUID is usually written on the box the PC comes in.

dim SystemSet Set SystemSet = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2").InstancesOf ("Win32_ComputerSystemProduct") For Each SystemItem In SystemSet szUUID = SystemItem.UUID If szUUID = "FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF" Then boolWFMCapable = 0 GetUUID = "" Else GetUUID = szUUID boolWFMCapable = 1 End If Next MsgBox GetUUID netbootGUID is the name of the attribute in Active Directory that stores the UUID. EDIT: Tweaked the script fragment to it will run standalone

Set folder permissions as follows Administrators: Full Control (This folder, subfolders and files) - So you don't lose control! Creator Owner: Modify (Subfolders and files) - When someone creates a file, they get Modify access to it Students: Read & Execute (This folder, subfolders and files) - Students can read all files Students: Create Files/Write Data & Create Folders/Append Data (This folder and subfolders) - Students can create files/folders here and below System: Full Control - Just in case! You'll need to go into the 'advanced' dialog to set these permissions. I suggest you test carefully before rolling this out, as complex permissions can lead to unexpected outcomes! Bon chance!

Just thought of another way...MyCmdLine = Replace("$$C:\Path with spaces\file.dat$$", "$$", chr(34))

If you are starting to lose track of things, then you can always use chr(34) MyCmdLine = "App.exe " & chr(34) & "C:\Path with spaces\file.dat" & chr(34) Sometimes it's easier that way. The other thing I do is to create an Enqote function function Enquote(sSource) Enquote = chr(34) & sSource & chr(34) end function Then you can do MyCmdLine = "App.exe " & Enquote("C:\Path with spaces\file.dat")

You only need the GUID before the build if you want to prestage the computer account in a particular OU. If you don't do this, it should still be creating a computer account (by default it's in the Computers container) and putting the PC on the domain.

Repackaging is like a bit like this

Assuming students are working from a single mandatory profile, then you could cache it on the PC. Get a Startup Script to copy the profile down to somewhere like C:\Profiles\Students. Configure the user accounts to get their profile from C:\Profiles\Students. Obviously you will need to set the appropriate security on C:\Profiles\Students so that the students cannot mess with the files. It might even improve logon times. If you use Robocopy in the Startup Script, then even if the profile is large, it will only have to be downloaded once.

According to an MS 70-270 exam, the way to prevent users logging on whilst disconnected from the network is to set the 'cached logon count' to 0. That in combination with the 'logoff when roaming profile fails' should do the trick.

It seems we've inadvertently stumbled on a significant quantity of the missing. so called 'dark matter' which is meant to be out there.

Right click the assignment and select 'redeploy...'

I think that's 'sot of nice', but probably more confusing than anything else. When you get a support call from a user unable to access a file/folder and they are getting 'access denied', then you know what you need to do. If you get a support call from someone saying 'I can't find....', then first of all you have to establish that they are in the right place and only then do you twig that it's a permissions issue. Any examples of when this feature would actually benefit anyone? (bearing in mind that if all you want to do is hide a folder, it needs to be a sub-folder of a folder that those you wish to hide it from cannot read).

I have one share for all staff and one for all students.. unless I have to cope with any Win9X/ME PCs. The only problem I've noticed is that Office (might be certain versions only, I have not checked) likes to have explicit traverse access to the folders above the user folder but below the share. So if D:\User\Staff was shared as 'staff' and subfolders were individual user folders, then you would need to make sure 'Authenticated Users' have 'traverse' rights on D:\User\Staff (this folder only).

What about install a PowerPoint player and seeing how that behaves. Not a solution, just trying to see what works and what doesn't.

How many PCs do you have that display this problem?