adamt

Thanks for the note about the * prefix in RunOnce. I never knew about that before - very useful.

Safe mode's going to be the problem here. When in Safe Mode, the startup folders and Run keys will be ignored, and only a minimal set of services will be running. I'm not sure if the Task Scheduler Service will be running in Safe Mode or not (I doubt it). If it is, you could (before the reboot in to safe mode) get the script to add a task to run SpyBot, using the at.exe command.

Now that I think about it, try this and see if it fixes things: regsvr32 shell32.dll If that doesn't work, a slightly better way than opening explorer each time, and then keying in the patch would be to type: explorer \\UNC\path in the run dialog.

Firstly, that isn't a URI, it's a UNC. URI = /home/page.php URL = http://www.example.com/home/page.php UNC = \\example\home\page.php Sounds like the association for a UNC has been broken. It should probably be set to explorer.exe Not sure whereabouts in the registry this lives, but it'll be somewhere under HKEY_CLASSES_ROOT My google is failing me on this one. Perhaps someone else here will know a bit more.

Have you tested the RAM yet? I tend to suspect that as the cause of BSODs if it's just been changed. Give http://www.memtest86.com/ a try, and see what the diagnostics say. The drive letter of your DVD drive should be decided by Windows. Run diskmgmt.msc, find the DVD drive, right-click and choose 'Change drive letter' - see if you can assign it to something sensible.

Found this: http://books.google.com/books?id=EVBio3-Ju...zBF6c#PPA320,M1 While googling around. It refers to Windows ME, but seems to describe exactly the same issue you're having. Let us know if the workaround works for you.

Können Sie auf Englisch schreiben, bitte? Ich verstehe nicht.

If you can already drag and drop files on to the DVD-RW icon in explorer, you should just be able to find your SendTo folder, and put a shortcut to it. Problem is going to be that it's an external drive, and may not always be present, or even on the same drive letter. If it's always likely to be on the same drive letter, create the shortcut in %USERPROFILE%\SendTo

You can change the order by editing the file C:\BOOT.INI The file will be hidden, read-only and marked as System, so you'll need to do something like: attrib c:\boot.ini -S -H -R Before you can make changes to it. I'm sure XP has a nice GUI way of changing the settings in boot.ini, but I don't remember what it is.

That will list every file in every directory, unlike TREE, which just shows directory structure. You could modify that DIR statement with a /A:D switch, so that only directories are returned.

See: Embedding an icon into your EXE or DLL: http://tlaughlin.pandorasystems.com/blogs/...exe-or-dll.aspx - This explains how to do it with Visual Studio.NET

Just tried this on mine and found the same thing. The bizarre characters don't show up if you run "type list.txt" - so I'm guessing it's some ASCII characters that notepad doesn't understand how to render properly in the transition between UTF-8 and Unicode. If you just run the TREE command, you get pretty lines showing the directory structure. If you view the output using the TYPE command, they can appear as dots or lines (depending on which font you use), and if you view the output using notepad.exe, they appear as the funny Aa type things. According to charmap, the character is a "Latin capital letter A with Diaeresis".

Are all your XP clients running SP2? If not - do you find that it works with XP SP1? Also - just to eliminate any other errors - have you tried dcdiag and netdiag to see what they show? Can you do both: net view \\PARENT and net view parent.fqdn.co.za ?

Have you tried running "dcdiag /v" on the domain controller and "netdiag /v" on an affected workstation? What do they tell you? Might be easier to restore a copy of SYSVOL from before the problem started and then find the GPOs by their GUIDs and perhaps see what's different about them now.

Thanks for the heads up - will take a look at writing a 'proof of concept' piece of code now.

After synching the time, did it solve the problem?

Few questions: Does MSIE use a proxy server to access the ftp site? - If so, I'm not sure if the network places wizard will be aware of the proxy. To work out if a proxy is needed, try to run ftp.exe ftp.example.com from the command line and see if you get a response. Are you specifying the protocol with ftp://ftp.example.org/ - or are you just adding it as ftp.example.org ? Does the FTP site need a username/password to access it when you open it in MSIE? - if so, does it work using a URL like ftp://username:password@ftp.example.org/ ?

Sorry, I was also looking at the opening request of "Is there a way to stop content that is viewed from a network share from being copied?" The fact is- the mere act of viewing a file means that a copy is made of it. Also consider printing - if the user can print your files, they can copy them (eg Document Image/PDFwriter printers, print to FILE, etc) I'd strongly suggest you look at Rights Management Services.

Turn on failure auditing for system events, object access and privilege use on the machine, then try again and see what's happening in the security log. That should give you some idea of which privs you're lacking. The only one I can think of would be "Load and unload device drivers", and that's assuming diskeeper's defragging engine works as a device driver. Run secpol.msc, open Local Policies, User Rights Assignment. Administrators should be in the effective setting against "Load and unload device drivers". Also have a quick look in the application and system logs to see if either the windows installer or diskeeper is writing any useful information to them. Finally - you could try running filemon/regmon or procmon to see if perhaps it's just a matter of there being something you need to take ownership of and grant permissions to.

You will probably need a proxy server. Google for ISA Server, or for SQUID.

You'll have to design your AD with the way your organisation works in mind. Start with: http://technet.microsoft.com/en-us/library/Bb727085.aspx

Dear all, I have a server which had a BSOD (STOP error if you will) with the bugcheck of 0xdeaddead According to MSDN, this means that a crash was manually initiated (see http://msdn2.microsoft.com/en-us/library/ms797162.aspx and http://support.microsoft.com/kb/244139 ). Problem is that it couldn't have been. Firstly - a registry key would need to have been added to enable manual crash, but it wasn't present on the server. Secondly - the server is locked away in a datacenter, and a manual crash dump would need to have been initiated at the console. The server is not running a checked build of Windows, either. Any ideas?

Fix the time problem first, as this can cause problems with GPOs (and many other things in AD). On the affected servers and workstations, login as admin and run: net time /set /y in the command prompt Also - what permissions do non-admin users have to those folders with GPTs in them?

You *might* be able to re-map the printscreen button to something else. Take a look at: http://www.microsoft.com/whdc/device/input/w2kscan-map.mspx - it's not entirely a secure, nor indeed elegant solution. As for stopping people from being able to save copies elsewhere - I don't think you really understand how these things work. Even if you could prevent people from doing File... Save As... - what's to stop them taking a copy out of their C:\TEMP folder? Or copying and pasting? You might like to try looking at Rights Management Services - http://www.microsoft.com/windowsserver2003...mt/default.mspx That will provide you with a fine level of control over your documents.

Are you a member of the Domain Admins group? Do you have permissions on the various GPT.INI files in the SYSVOL shares? What GPOs does RSOP.MSC show when you're logged in? Make sure you're checking the logs on the DC that's authenticating you, which isn't necessarily the one you're logged in to.