ajbritton

Congratuations :-) I'm sure you're tired of people telling you that you don't know what you're letting yourself in for, so let me just say that you will have some wonderful times ahead as well as all the sleepless nights. My wife is also expecting our second child any day now so I too may be a less frequent visitor on the site.

You are correct - It is the computer accounts which need the policy applying. Whereabouts did you create the OU (as in what is the OUs parent object)? I'm guessing that you've ony just started with OUs. If so, there is a thread somewhere on the site relating to suggested OU structure. It might be worth a look to see how other people have structured their OUs.

Be careful! When I got the urge to convert my logon script to .VBS (or .WSF in my case), I ended up with a several hundred line behemoth which in some ways is less manageable than the old .BAT file !!

First of all, try moving one of the computer accounts out of your new OU and back to wherever it came from. Reboot the PC a few times (so that policy gets applied) and test logon as a user. If logon is OK, then it must be to do with the policy applied on the OU. Use Group Policy Management Console (GPMC) RSoP feature to show all the policies that apply to computers in the OU. This should show where the policy is coming from. IIRC there is a user 'right' called 'log on interactively). I think this would be controlled by a policy under Computer Configuration, Windows Settings, Security, User Rights (or similar). Hope this helps.

Have a look at the Windows Setup Timeline. If I understand correctly, the driver you copy into the i386 folder is only used by Text-Mode Setup. Once the PC reboots and goes into the GUI-Mode Setup, the driver is no longer loaded. Devices are then detected, but BEFORE the network is installed. This would mean that when device detection takes place, there is no network connection. I tend to agree with Chris and Elusiv on this one. Bung all the drivers in $oem$ and copy them down to the C: drive. If space on C: drive is a problem, you could always delete the drivers once installation is complete.

If your network driver is one of those that is is loaded during PnP device detection, then it stands to reason that Windows won't have access to the network until that has happened. I don't know what order drivers are detected/installed, but it seems to me that it's going to be very tricky to get this working. You could try a script which runs after the network is up and running, which deletes all unknown devices and forces a redetection. Also, you would need to make sure the computer has access to the files on the share. Try adding the 'Domain Computers' group to the root of the share.

@SpuffMonkey: Any reason why you are using .BAT? Try renaming it as a .CMD I've never tried running .BAT files from GPO assigned logon scripts, but .CMD should be no problem. .BAT files are executed by COMMAND.COM whereas .CMD are executed by CMD.EXE. If the change works, then it may be something to do with this difference.

When in doubt, I try changing a few things to see what happens.. Try running a logon script of a different type... Create a simple .VBS logon script eg. msgbox "I'm the logon script" Save it as TEST.VBS and test it by double clicking. You should see a simple message box. Now add it to your GPO as a logon script (I would remove the link to the original so that TEST.VBS is the only script). Now try the logon and see if it works.

Not at all - I didn't realise you could - how do you do that? Easy... Go to GP editor, User Config, Windows Settings, Scripts, Logon, properties, then I think it's 'show files...'. This will bring up an explorer window. Drag the files in here then close the window. No when you click 'add', you should see the script.

Possibly something to do with ADM templates... http://www.derkeiler.com/Newsgroups/microsoft.public.windows.server.security/2004-03/0189.html

Is there any reason why you don't leave the script in the GPO?

OK, I know it's a rip-off but how about... [align=center]www.edugeek.net "Hello, IT ... have you tried turning it off and on again?" [/align]

For RAID 0 to give any kind of performance benefit, the data MUST be divided between the disks which would surely mean that any data recovered from one disk is going to be swiss cheese at best. If it's the case that the blocks are split alternately between the two disks then you'll only recover half the blocks. Even with a large block size, the data will be full of holes!

Really? I thought they ran in the user security context. Is there any MS documentation on that?

Right... at which point you get the WEP key. So now you can sniff packets and get free Internet and potentially use password cracking tools. My point being that there is (or at least should be) a whole lot more security still to get through if you are after the serious data (pupil files, financial info). I think I'm right in saying that Windows passwords no longer travel across the wire unencrypted, so it should not be a trivial matter to obtain a password. I also believe it is possible to encrypt all network traffic using IPSec between Windows clients and servers. Doing that would mean that even if the wireless network was compromised, the data on the network and servers should still be safe. Don't know what kind of hit this would have on performance though. I assume encryption would be done symmetrically (same key to encrypt/decrypt) and key exchange using some form of public key transfer. (Bit out of my depth here!!)

It depends how secure you want it. I don't think MAC address filtering is generally considered to be highly secure as any MAC address can be spoofed. A determined hacker should be able to get past MAC address filtering without much trouble. Having said that, it might slow down and possibly deter the casual opportunist. There's really no excuse for not using the highest level of WEP encryption available on you APs and Laptops. WEP adds another layer which, although no longer considered secure, will deter all but the serious hacker.

My standard method is based on a command script which does the following; 1 - Call the EXE which makes a SIMS backup (admin servers only) 2 - Create a new tape name (based on date/time) 3 - Execute NTBackup with a predefined .BKS selection file The whole thing runs as a Windows scheduled task (not via NTBackup) under the security context of a dedicated backup user account that has Administrator level access. The system works fine as long as the data fits on a single tape. I don't think this solution would be useful for anything but the simplest of sites but I thought I'd throw it it to show how penny pinching I am!

I've tested the Internet blocking on LNM and it seems to work. It's possible to block and entire room (lab) or individual computers. It takes effect immediately. The only problem that I can see is that it is based on modifying the Default Gateway IP address on the PCs. That's fine, unless you have an on-site proxy server!

There's even hope for 802.1x. Have a look at Mike Mullins' posts.

Further investigation reveals a MOVE.VBS which is executed by CMDLINES.TXT. The script interrogates C:\Windows\system32\$winnt$.inf, looking for a ProfileName entry. The ProfileName refers to an OU. The script then looks like it looks up the computer account in AD and moves it to the appropriate OU.

ChrisH, Just a thought, but if you are prestaging the computers to get them in the correct OUs prior to installation by RIS, then you might like to have a look at the way Microsoft has used scripts in Learning Network Manager. When a PC is RIS built on this system, it is automatically moved to the correct OU. You might be able to get away with a SIF file for each OU...

Have you looked at this?

I have never had this problem on XP laptops, BUT, I do set a group policy which forces the clients to 'wait for network at startup' (or something like that). Policy setting... "Computer Configuration\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon" Set to Enabled I would also 2nd Netman about allowing Windows to do all the config and management.

Yep, uninstalling SharePoint appears to have sorted it. Does this mean it's impossible to use SharePoint on a server with any other web sites on it? Or do they just have to run on different ports?

I notice on my LNM server that there is an 'Internet Blocking Service'. I'm guessing this is to do with the facility whereby an entire 'lab' can be prevented from accessing the Internet. Anyone know anything about this? It might be a useful component if it could be isolated.