nmX.Memnoch

Yes, this can be done on the Account tab of the user account properties...except that it's the reverse of your question. Using the Log On Too... feature you specify which machines the account can login to, not which ones it can't. The only thing is you have to do it by computer name, not by the OS.

I'd recommend going 64-bit everywhere that you can...particularly if you're going to be using more than 4GB RAM. Obviously there may be some applications that may not run correctly or at all on the 64-bit version so you'll need to look into this. Of course, this also depends on whether or not the hardware will support a 64-bit OS as well.

There are no policies for user groups. Only machine and user policies. "GPO" does indeed stand for "Group Policy Object", but that's domain level terminology and does not corrolate to user groups in the way that you're thinking. Or just choose Event Viewer from Admin Tools. It's also located in Computer Management.

That should've been mentioned in the OP. You posted in the WinXP forum, which is why several of us said not to make them admins.

The first thing that comes to mind when people mention "IDE" and "Western Digital" in the same sentence is to check the Master/Slave jumper. If it's a single drive (only drive on the cable) then there should be no jumper at all on the drive. If it's a single drive and you have the jumper set to Master, it won't be detected. This is an oddity only with WD drives...

DC's don't reqeuire Enterprise Edition although most tend to use Enterprise in a larger environment (where more RAM can be helpful). Here are the features that 32-bit Enterprise will give you over Standard: - Support for 4 CPUs (this might be 8 now) vs 2 CPUs - Support for 32GB RAM (using PAE) vs. 4GB RAM - Support for Clustering That's the main feature upgrades anyway...

Yeah, we tried putting the latest drivers on the 2000 server. The 1320 drivers are just sloooooooow. Things sped up quite a bit when it was changed to use the 4050 driver though.

1. Run the regedit and navigate to HKLM\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions. If this registry subkey does not exist, create it. 2. Right-click the ItssRestrictions subkey, point to New, and then click DWORD Value. 3. Type MaxAllowedZone, and then press Enter. 4. Modify the MaxAllowedZone value to 1. 5. Quit Registry Editor. Setting it to 1 allows both the Local Machine Zone and the Local Intranet Zone. A setting of 2 would also allow the Trusted Sites Zone (1 is all you need for them to work from network shares). EDIT: Woops...just noticed that Mijzelf provided a link. Oh well...at least now he doesn't have to click the link.

Wouldn't it just be simpler to buy a keyboard conceived for the PC? PS2 keyboards are for losers. Ever heard of USB keyboards?

Well...this all depends. Generally an application contains global settings in HKLM and user settings in HKCU. Those settings aren't usually the same between HKCU and HKLM. Yes, there may be common keys, but the values are usually different. Sometimes they are the same, in which case HKLM should take precedence. As far as system policies, HKLM should take precendence, depending on the policy.

As long as you have it specified on a user they should be seeing it every time they login. We have a consent statement that we have to agree to every time we login. Personally, I would just leave it in place and maybe just comment out the part that logs the output. BTW, you can leave the script on all of your users and just comment parts out. For instance, if you wanted to comment out the MessageBox just put a /* before $X = MessageBox line and a */ after the EndSelect line. Alternatively you can just put a ; at the beginning of each line. Again, I would recommend looking into AdminScriptEditor. It's not free, but it's not as expensive as some of the other editors out there. It also supports editing AutoIt, VBScript, CMD, BAT, XML and a several other languages. They're getting ready to release version 3.0 that will also add support for PowerShell. I've found it hard to beat some of the features as well.

Lucky guess... Actually...I'm doing a side job for a friend and he's got a bunch of those on his network. Same situation...Win2k Server and WinXP clients. The drivers for them are horrid. We both did a little research and found you can use the HP 4050 drivers. It helped in his situation some but the print spooler is still acting up every few days (which is better than a few times a day). Fortunately we're in the process of setting up a new server that's running Server 2003 R2. HP also has their new Universal Print Driver but I haven't tried it yet.

Well...you won't be telling them a lie. Those two settings are connected...you can't disable one without the other.

Wouldn't happen to be an HP 1320 would it?

Basically he wants it like the old Win9x screensaver passwords. AFAIK, that's not possible in an NT based OS.

Here's what you need to do. - Make your KiX script. I'll use "logon.kix" for the purposes of this example. - Make a batch file. In this instance I'll just use "logon.bat" for the filename. The contents of logon.bat should be: %0\..\KIX32.EXE %0\..\logon.kix - Copy logon.bat, logon.kix and KIX32.EXE to the NETLOGON share of one of your domain controllers. They'll automatically replicate to other DCs from there. - In Active Directory Users and Computers double click a user. Go to the Profile tab and under "Logon script:" enter logon.bat. Do this for every user that you want to run the logon script. Setting this option may be scriptable but I've never tried it. %0\..\ translates to the NETLOGON share of whichever server the user authenticates against. You can probably do this with a GPO but the problem is that I'm pretty sure you have to put the full path to the executable and the script in the batch file. I can play around with this, but I know for a fact that setting it up as the user logon script on the user's account works. I know it's a pain setting the option on every user...but you only have to do it once (and of course remember to do it on any new users). If you want to test it with your GPO then just edit your batch file like so: \\domainname.tld\SYSVOL\domainname.tld\Policies\{GPO_GUID}\User\Scripts\Logon\KIX32.EXE \\domainname.tld\SYSVOL\domainname.tld\Policies\{GPO_GUID}\User\Scripts\Logon\scriptname.kix Honestly though, I really don't think it'll work because those usually aren't displayed on screen.

But you expect one of us to do it in our spare time so you can save yours? I like to help people...but you have to be willing to do at least part of the work! IcemandND pointed you to a couple of articles that will do everything you want...all you have to do is a little copy and pasting with some minor editing.

Yep. Honestly though...you really don't need the monitor drivers. Usually the default Plug and Play Monitor driver works just as well...unless you're after the color profiles.

Well...first we need to determine if that actually is the problem. What happens if you delete the printer and manually re-connect it? Does it work properly then?

In your Default Domain Policy change the following options: Computer Configuration\Windows Settings\Security Settings\Account Policies/Password Policy Maximum Password Age = 0 Minimum Password Age = 0 Be warned that this will change it for every user in your domain. Using a GPO to accomplish this is a machine level setting, not a user level setting. Honestly, it's really not a good policy to never have the users change their passwords. If this is a stand-alone server (not in a domain) then use gpedit.msc to edit the same settings.

Here ya go. Tested and working. The only thing you should have to do is change the MessageBox text, create the share and point the RedirectOutput to your share. You can also put in other code between the EndSelect and :end. For instance, if you wanted to map drives for your users, read registry keys, write registry values (i.e. screensaver settings), etc, etc. Putting that extra code between EndSelect and :end would only run it for users that agree to the Usage Consent. ; Keep users from closing script -- Closing the script with Break set to Off will automatically log the user off Break Off $X = MessageBox("By agreeing to this statement you agree to abide by the usage terms blah blah blah", "Usage Consent", 4116) Select Case $X = 6 $Agreed = "Yes" Case $X = 7 $Agreed = "No" ? "NO selected, logging out...." Goto end EndSelect :end ; Convert @DATE into useable format for file/directory names $DATE = Split(@DATE,"/") $DATE = $DATE[0] + "-" + $DATE[1] + "-" + $DATE[2] ; Redirect output to agreement_YYYY-MM-DD.csv on hidden share $OUTPUT = RedirectOutput("<SERVER>\<HIDDENSHARE$>\agreement" + $DATE + ".csv",0) ; Begin output for agreement_YYYY-MM-DD.csv @WKSTA + "," @USERID + "," @DATE + "," @TIME + "," $Agreed + @CRLF ; Redirect output back to console $OUTPUT = RedirectOutput("") ; Logout is user does not agree to terms If $Agreed = "No Logoff(1) EndIf Exit

Using "start" won't work correctly unless he uses .cmd instead of .bat anyway. Also, qchain.exe shouldn't be necessary either.

If you do a lot of file transfers between the SATA and PATA drive then you'll probabaly see a slight performance increase. You may also notice a slight increase with CD burning (even if you leave it on the PATA controller with both drives on the SATA controller). At the very least there would be less of a chance of coaster making. Other than that you probably won't notice much...other than having better air flow, which will result in a cooler running system.

You really need to look into sysprep. Having every machine with the same SID can cause some serious headaches. The downside is that you'll have to drop them from the domain to run sysprep and then rejoin them after running sysprep. Before rejoining the computer account in the domain will need to be reset. The latest version of sysprep is included in the XP SP2 Deployment Tools.

As long as all of your computers are running WinNT 4.0 or newer you can just have the executables on the NETLOGON share. Then create a batch file with the following line: %0\..\KIX32.EXE %0\..\scriptname.kix Then all you have to do is set the batch file as the users' logon script (this is done on the profile tab of the user account). This can be done with KiX as well. You'll need a hidden/unadvertised share that all users need write access to though. Give me a little bit and I'll work up some simple code that will dump the information to a CSV. It's a PITA to get working correctly but you can have KiX dump straight to Excel or Access as well...for that matter, I'm pretty sure you can have it dump to a SQL database.