cluberti

That has to be one of the least helpful posts I've ever seen in describing a problem. The title of the post gives no indication of what the problem is (hint: read the forum rules!), and the post is woefully short on any useful information. Here's what I got from your post: You have nero, 7.0.1.4b, and you have an error. These may, or may not, be related. You followed some steps to do something, but what those steps were, or what you are trying to accomplish, is not clear. Perhaps you should restate your post, answering the following questions: 1. What is the exact error you are seeing, either on screen or in the event logs? 2. What were you doing, exactly, when this error occurred? 3. What steps did you take leading up to the error, as best you can remember? 4. What product or products are involved in this - is it a Windows error, a Nero error, or both? 5. Can this error be reproduced at will, or was it a one-time occurrance? If you can answer those questions, we might be able to help. Otherwise, your post will go unnoticed and unhelped due to lack of information.

You should probably post this in the nLite forums.

I second the layout suggestions - if you want to do GP filtering downlevel, you should apply the LEAST restrictions (or none at all) to the top-level domain policy, and get MORE restrictive the farther down the OU and GPO tree you go. Also, remember that policies with overlapping security settings will use the LOWEST GPO to the user or machine in question, not the highest. Also, it is better to make changes and restrictions apply in the User Configuration tree, rather than the Computer Configuration tree. Most GP settings are found both in the User and the Computer container, and making sure each user gets the right policies is easier when policies are configured for the user, rather than the machine the user uses - they may not always use the same machine, but they're likely to always use the same user account. Just some food for thought, slightly OT, but probably still relevant.

If you are a true Linux newbie, which it seems you are, you may want to try one of the more "newb-friendly" distributions like Knoppix. You can either install it, or run it directly from the CD (known as a "live-cd"). I would suggest you get your feet wet that way (Knoppix, perhaps live-cd) before installing a full-blown and somewhat less newb-intuitive distribution like Gentoo. Don't get me wrong, Gentoo is great, but like all flavors of Linux it does require some user-configuration post install to get things working "just right", whereas the live-cd of Knoppix makes no such claims, and runs pretty good right off of the CD. Good luck .

Then no - without the source binaries, you get no languages. They aren't included in the default install unless you specify them, and installing them later requires the source binaries on the CD. You MAY be able to get the files off of another machine with that language pack installed, but you'll have to hunt and peck for the right files.

Is that an NF4 board? If so, I've heard using older drivers (6.67, I believe) with some modifications works. Not sure about how accurate that is because I don't have a board with that SATA set, but I have read of it working on multiple sites with older WHQL drivers.

Certainly you can. Just make sure to define options "66 - Boot Server Host Name" and "67 - Boot File Name" in your DHCP server. Mine is configured as follows at remote sites: 66 - server.domain.tld 67 - \OSChooser\i386\startrom.com Good luck.

I would install NT4, then SP6a, then the SRP (Q299444), then IE 6.0SP1.

Check the following registry key: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan Value: ObjectName Type: REG_SZ Data: LocalSystem If ObjectName is not set to LocalSystem, change it. Reboot for changes to take effect.

1. Make sure that your lockout reset is 15 minutes or greater - we do see sometimes that when the lockout reset count is less than 10 issues can occur. It is Microsoft suggested policy to set it to 15 minutes or greater. 2. Enable the following auditing options in the domain GPO (in default domain security policy of the child domain): a. Account Logon Events - Failure b. Account Management - Success c. Logon Events - Failure 3. On all domain DCs, enable Kerberos event logging according to the following KB article. The DC's will have to ALL be restarted before this starts working properly, so schedule some downtime for each DC (they do not all have to be done at once). 262177: HOW TO: Enable Kerberos Event Logging http://support.microsoft.com/?id=262177 4. Enable netlogon log on the all domain DCs by modifying the following registry entry: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon Parameters\DBFlag The detailed steps can be found in the following Knowledge Base article 109626: Enabling Debug Logging for the Netlogon Service http://support.microsoft.com/?id=109626 When the account lockout issue takes place, collect the following information for further problem investigation: 1. The account name that is locked out. 2. The security log (EVT format) of the all computers that are involved with the client's lockout (the PDC, the authenticating domain controller, and the client computer that have user session). To find out the authenticating domain controller, type "Set L" (without the quotation marks) at a command prompt on the client machine. 3. The netlogon.log generated from the PDC and the authenticating domain controller. Review that data and you should have a better idea of what is failing, and why.

This could be a hardware problem, but it would be good to know if this is indeed a reboot, or if this is a bugcheck that isn't being reported due to the automatic reboot. I strongly suggest following mmX's advice and configure the machine accordingly.

If you have the following set: gpedit.msc (or group policy on a domain) Computer Configuration Windows Settings Security Settings Local Policies Audit Policy Audit account logon events - Success, Failure Audit logon events - Success, Failure You will see the logon and logoff events in the security log of the server.

Just copy them into a new text file, and rename them to .vbs - then open a command prompt and run. No need for a compiler. Also, printmig may work but it's a crapshoot against remote systems - stick to the vbscripts, they work 100% of the time.

Ethereal can read .cap files, as can Microsoft's Network Monitor utility. You should also not be getting errors on shell32.dll, so that is a concern, and needing access to a systemprofile folder may be necessary for 3rd party printers (although you may still want to contact them, you likely won't get anywhere). I've seen that before on HP printers.

Are you logging on at the console?

For printers: On Error Resume Next Const wbemFlagReturnImmediately = &h10 Const wbemFlagForwardOnly = &h20 arrComputers = Array("<computer names here, comma-delimited>") For Each strComputer In arrComputers WScript.Echo WScript.Echo "==========================================" WScript.Echo "Computer: " & strComputer WScript.Echo "==========================================" Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_Printer", "WQL", _ wbemFlagReturnImmediately + wbemFlagForwardOnly) For Each objItem In colItems WScript.Echo "Name: " & objItem.Name WScript.Echo "ServerName: " & objItem.ServerName WScript.Echo "ShareName: " & objItem.ShareName WScript.Echo WScript.Echo "DriverName: " & objItem.DriverName WScript.Echo WScript.Echo "Location: " & objItem.Location WScript.Echo WScript.Echo "Comment: " & objItem.Comment Next Next Function WMIDateStringToDate(dtmDate) WScript.Echo dtm: WMIDateStringToDate = CDate(Mid(dtmDate, 5, 2) & "/" & _ Mid(dtmDate, 7, 2) & "/" & Left(dtmDate, 4) _ & " " & Mid (dtmDate, 9, 2) & ":" & Mid(dtmDate, 11, 2) & ":" & Mid(dtmDate,13, 2)) End Function For mapped drives: On Error Resume Next Const wbemFlagReturnImmediately = &h10 Const wbemFlagForwardOnly = &h20 arrComputers = Array("<computer names here, comma-delimited>") For Each strComputer In arrComputers WScript.Echo WScript.Echo "==========================================" WScript.Echo "Computer: " & strComputer WScript.Echo "==========================================" Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_MappedLogicalDisk", "WQL", _ wbemFlagReturnImmediately + wbemFlagForwardOnly) For Each objItem In colItems WScript.Echo "ProviderName: " & objItem.ProviderName WScript.Echo "FileSystem: " & objItem.FileSystem WScript.Echo Next Next Function WMIDateStringToDate(dtmDate) WScript.Echo dtm: WMIDateStringToDate = CDate(Mid(dtmDate, 5, 2) & "/" & _ Mid(dtmDate, 7, 2) & "/" & Left(dtmDate, 4) _ & " " & Mid (dtmDate, 9, 2) & ":" & Mid(dtmDate, 11, 2) & ":" & Mid(dtmDate,13, 2)) End Function

Run regmon and filemon (www.sysinternals.com) when starting the service, and you should see where the problem lies - either a file not found, an access denied, a registry key you can't read or doesn't exist, etc.

http://support.microsoft.com/default.aspx?...kb;en-us;555324 Google is your friend - use it .

Yes, that utility exists for all 3 OSes. You can also use the "at" command as well, just for reference.

If we're talking about Terminal Services, or you're logging on as a non-admin user, then this is expected behavior.

What happens if you boot without a network card plugged in? Also, if you download autoruns (from www.sysinternals.com) and disable all non-Microsoft items, does the slow boot problem persist? Slow boot problems are actually caused by drivers not coming online fast enough, or services either not responding to Service Control Manager requests in a timely fashion or dependancy issues (where one service others are depending on starts up very slowly, causing the rest to start slowly).

The error is actually coming from both advapi32.dll and rundll32.dll. I usually only see these errors when one of these two files are not registered correctly, or weren't updated correctly in the last update that touched these files (either a hotfix or service pack installation), meaning mismatched files. It would be prudent to run sfc /scannow to make sure all of your dllcache and system files are of the proper versions, then visit Windows Update and reinstall any hotfixes listed there. That should resolve the issue. Also, copying the files from a Windows 2003 machine to an XP machine will not work.

Right - since a normal user can simply run: at <hh:mm> /i "cmd.exe" And get a command prompt running as the SYSTEM account in interactive mode - basically complete control of the local system without knowing ANY passwords other than his or her own.

Can you get a network trace of the print job failing? Install the support tools off of the Windows XP CD and then run netcap /? to give you an idea of how to get a capture. It may also be prudent to get a regmon and filemon capture at the same time (both tools from www.sysinternals.com). One of these three tools should show us where the ACCESS DENIED error messages are coming from.

Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. >cscript /? Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. Usage: CScript scriptname.extension [option...] [arguments...] Options: //B Batch mode: Suppresses script errors and prompts from displaying //D Enable Active Debugging //E:engine Use engine for executing script //H:CScript Changes the default script host to CScript.exe //H:WScript Changes the default script host to WScript.exe (default) //I Interactive mode (default, opposite of //B) //Job:xxxx Execute a WSF job //Logo Display logo (default) //Nologo Prevent logo display: No banner will be shown at execution time //S Save current command line options for this user //T:nn Time out in seconds: Maximum time a script is permitted to run //X Execute script in debugger //U Use Unicode for redirected I/O from the console