Blog: Windows XP

Find the container for the software within the Uninstall path in the registry.  Usually there is a description within that says what program it is tied to.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*Install Container*

Registry DWORD values that can be added are “NoRemove”, “NoRepair”, and “NoModify”.  Setting these values to 1 enables the setting or use 0 to disable.  You can use these settings to keep users from manually being able to remove, repair, or modify specific programs.

I cloned a Windows Desktop XP machine and could not access the machine via RDP.  I found that if I edited the registry with a key AllowDirectRDP=True, then I could RDP to the desktop. After researching the problem, I found that this behavior is “by design” for Virtual Desktop Manager “managed” machines. However, I do not believe the original machine was managed by the VDM, but it could have had roots in such a machine. 

Here is the relevant KB article from VMWare.  http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006042

Processes can be remotely viewed and terminated by built in Windows commands: tasklist.exe and taskkill.exe.

Examples of terminating a process:

Find the process id using the command “tasklist /s <computer> /u <domain>\<user> /p <password>”

Terminate the corresponding process “taskkill /s <computer> /u <domain>\<user> /p <password> /pid <process ID>”

Out of the box, Windows XP doesn’t have Remote Desktop enabled for connecting in to the PC.  You can access the registry of the remote machine and change the setting that will allow access (at least to administrators).

The target PC must have remote registry service enabled.  If it isn’t, you can open services.msc and connect to the remote PC and start it.

The next step is to open regedit and connect to remote PC.  Look for the following Registry key:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\fDenyTSConnection

Set the value to 0 to enable Remote Desktop, or 1 to disable.

We had a problem with a computer that could not be connected to via RDP. There were no errors. It would blink the connecting message up on  the screen and then goes away but it never actually connected. This was a windows XP machine (I think with SP2 or 3) and had all of the configuration set correctly. The server could contact everything on the network regularly and it could be pinged from other PCs, connected to through WMI and SMB. The firewall was disabled as well. After some research I found that some had this same problem and had fixed it by updating the video card drivers. Not really expecting much results but with few options at this point I decided to update the video card drivers on the problem machine. Sure enough updating the Video card drivers fixed the problem.

Just a friendly reminder at how easy it is to gain access to your files if your machine is running. I locked myself out of a Windows Vista virtual machine I was playing with (It wouldn't allow me to log onto the domain and I didn't have the local admin password). After some quick Google searching, I ran across the free Offline NT Password and Registry Editor. You boot to a light distro of linux, it copies the SAM database, asks what you want to do with the password (in this case, clear it), saves the SAM database back, and presto! You're in.  This also illustrates the importance of implementing full disk encryption.

Many years ago, PC makers came out with the “enhanced keyboard” and the control key got moved.  It used to be located to the left of the caps lock key, but for some reason that is still unknown, it got moved to way down below the left shift key, where you really have to cramp up your hand to reach it. The most popular solution to this is to switch the caps lock and the control keys.  I use a nice GUI program, KeyTweak http://webpages.charter.net/krumsick.  Since NT, Microsoft Windows has had a registry key that lets you remap your keyboard. This lets you remap just about every key by setting this registry key.  It is the most complete utility I could find.  It works with Windows NT/2000/XP/Vista/Win 7. Since this is a feature built into Windows, no kernel mode driver, service, or anything else needs to be running. You can edit the registry yourself, but this tool makes it really easy.  It has an option to show the registry entry and what all the bytes mean.

During IT audits, we routinely see banks granting all or some of their users local administrator rights on their PCs.  They are usually forced into allowing this level of access due to some software that will not work correctly without local administrator rights.  However, they can mitigate some of the risk by using a utility called DropMyRights.

In a recent Security Now! podcast, Steve Gibson talked about the DropMyRights utility.  It was written by a Microsoft engineer.  It allows you to run specific programs with less rights than your user account normally has.  For example, if you are given local administrator rights because the core banking software requires it, you can use DropMyRights to help protect yourself when running web browsers or your email client.  Simply create a shortcut for each program using DropMyRights in the command line.  For example, you could use the following command line to run Internet Explorer under a non-admin user context: [more]

C:\utilities\dropmyrights.exe "c:\program files\internet explorer\iexplore.exe"

I recently ran into a problem trying to restore a SQL Server 2005 database to a Windows XP machine.  The database back up was created on a Windows Vista machine and I thought that the different OS versions was the culprit.  However, it turned out to be related to SQL server instances and folder paths.  Here is full error I received when I attempted to restore the database using SQL Server Management Studio:

Restore failed for Server 'localhost\sqlexpress'.  (Microsoft.SqlServer.Express.Smo)

Additional information:
System.Data.SqlClient.SqlError: The operating system returned the error '5(Access is denied.)' while attempting 'RestoreContainer::ValidateTargetForCreation' on 'c:\Program Files\Microsoft SQL Server\MSSQL.2\MSSQL\[my database name].mdf'. (Microsoft.SqlServer.Express.Smo)

I searched the Internet using the error message and found several posts stating that it was a problem with the privileges of the user account that my SQL Server Express service was running as. I hadn't changed the account it was running as and I had restored other databases in the past, but I checked the SQL Server Configuration Manager anyway.  As I suspected the service was still running as the default account (Network Service), so that wasn't it.   [more]

After I couldn't find a quick fix on the Internet I decided to look around the options in the Restore Database window.  It turns out the problem was with the paths under the restore options.  The backup was trying to restore the .mdf and .ldf files to the c:\Program Files\Microsoft SQL Server\MSSQL.2\MSSQL\ directory.  The instance of SQL Server I was working with was storing all it's data files in C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\.  Once I changed the paths for the database file and log file to be the same as where my other database files were being stored the restore ran fine with no errors.  For additional reference, here is an article that explains the naming of folders for SQL Server 2005 instances: http://weblogs.sqlteam.com/tarad/archive/2006/06/07/10114.aspx