Wednesday, August 29, 2007

How to give Read-only access to Event logs to particular users

Sometimes it is necessary to permit certain groups of people access to event logs on domain controllers or other servers in the domain. The most common request is read-only access to various event logs to enable delegated administrators monitor the logs. A good example is giving DNSAdmins read-only access to the DNS event logs.

The process is very cryptic and involves modification of some registry keys. It is documented in the below mentioned KB articles:
How to set event log security locally or by using Group Policy in Windows Server 2003
You receive an "Access is denied" error message when you try to access an event log on a Windows Server 2003-based computer or on a Windows 2000-based computer

The default ACLs for each event log is below, which you need to start with as your base then add whatever additional ACLs you want:

Application Log:


Directory Services:


DNS Service:


File Replication Service:


Security Event Log:


System Event Log:


To add more groups or users to the ACL list, you first need to determine the SID of the user or group. It should start with an "S" and be quite long, such as S-1-5-21-702074188-2833732907-241959117-48998. You can use LDP or other methods to find the SID.

The SDDL syntax for adding read-only access to any of the logs above is:

(A;;0x1;;;<Insert SID here>), for example: (A;;0x1;;;S-1-5-21-702074188-2833732907-241959117-48998)

For the security event log the final ACL would look like:


Just cut and paste this into the GPMC for the right event log, and viola! Instant read-only access is granted to a specific user or group

-------------- End of Document -----------------

Tags: Windows XP, Windows Server 2000, Windows Server 2003

Published Date: 20070829

Tuesday, August 28, 2007

Run command to lock windows

Ever wondered how can you lock your computer using a script?

Just try typing the below line verbatim on the run window and hit enter. Presto! Your computer is locked.

rundll32.exe user32.dll, LockWorkStation

-------------- End of Document -----------------

Tags: Windows XP, Windows Server 2000, Windows Server 2003

Published Date: 20080828

Wednesday, August 22, 2007

Determine System configuration information of Windows box remotely

I always wanted to gather information such as CPU / RAM / OS Version / Installed OS patches / System Uptime / Installation date and other such details that are required for inventory purpose for Wintel boxes.

Systeminfo is a command line tool enables an administrator to query for basic system configuration information. Below is the parameter list of the command:

1. /S system: Specifies the remote system to connect to.

2. /U [domain\]user: Specifies the user context under which the command should execute.

3. /P [password]: Specifies the password for the given user context. Prompts for input if omitted.

4. /FO format: Specifies the format in which the output is to be displayed. Valid values: "TABLE", "LIST", "CSV".

5. /NH: Specifies that the "Column Header" should not be displayed in the output. Valid only for "TABLE" and "CSV" formats.

6. /?: Displays this help/usage.

This would help a lot in filling your h/w inventory sheets.

--------------- End of Document -----------------------

Tags: Windows XP, Windows Server 2000, Windows Server 2003

Published Date: 20070822

Sunday, August 12, 2007

Directx 9.0c wont install in Win XP SP2

When your try to install DirectX 9.0c over DirectX 9.0b in Windows XP SP2 OS it won't allow you to do so. When the installation begins, it goes straight into the "Installation Finish" dialog box.

This is a (stupid) bug from Microsoft's DirectX 9.0c installation program. Technically, the install program (setup.exe) will check the Windows version first. If it is Windows XP with SP2 installed, it will then check the DirectX version, but only the major version (the number behind the dot). If it is "9” (including 9.0a and 9.0b), the program will think that you already have DirectX 9.0c installed since most Windows XP SP2 installation already come with that DirectX version. Big mistake, isn't it?

So anyway, here's the solution for the DirectX 9.0c installation problem.

  1. Get DirectX Uninstall program. There are lots of them on the web. Search using "directx uninstall download" keyword will do. Most of them are freeware so don't worry about wasting extra money.
  2. Run the program you've just downloaded. I think all, if not most of them, will ask you to restart the computer. Do it.
  3. Once your computer restarted, your DirectX 9.0b (or 9.0a) is gone. Instead, you'll get the native DirectX 8.1 that comes with the original Windows XP installation.
  4. Download DirectX 9.0b distribution package. You will also need 9.0c distribution package, so download it if you don't have it yet. Extract them on any folder you want, for example: DX9B (for DirectX 9.0b) and DX9C (for DirectX 9.0c).
  5. Now here goes the tricky part. Copy all the CAB files from your DirectX 9.0c folder (DX9C) into your DirectX 9.0b folder (DX9B). Choose "YES" when prompted to overwrite files. Note that copying NON-CAB files from DX9B into DX9C might NOT work (It didn't work for me so I can't guarantee it).
  6. Run the DirectX installation program from the 9.0B folder (DX9B). DirectX 9.0c installation should work now. It works for me, so I hope it'd work for you too, guys!

--------------------------- End of Document ----------------------------

Tags: Windows XP

Published Date: 20070812

Tuesday, August 7, 2007

Interactive task’s GUI does not appear on System Console

If a scheduled task fires at such a time when no one is logged into the system, the GUI will not visible to the user if he logs in later on (even from the console). However the process would be running on the system. It happens because:

  1. The task is launched in the security context of the 'Run As' configured user of the task.
  2. Windows looks for an active available session for that user.
  3. If Windows finds a session the task is launched in that user's Desktop.
  4. If Windows does not find the user's sessions the task is launched as a background task.

However remember the task would be launched in the console session only if more then one sessions for the same user are active on the box. Running interactive schedule tasks in TS sessions is not advisable and can give unpredictable results.

In contrast if the Task was scheduled as an 'AT' task the GUI would appear to any user who logs in to the console. This is true even if the user logs in to the console after the task was fired up. The following things should be kept in mind for AT tasks.

  1. AT tasks run in the SYSTEM security context.
  2. An AT task cannot access network resources because it is NOT running as a user.
  3. You open an AT task in Task scheduler GUI and do anything, it no longer remains an AT task.

There apparently are two type of schedule tasks available in Windows:

  1. Tasks that are scheduled / created using Task scheduler GUI.
  2. Tasks that are scheduled / created using 'AT' command.

AT tasks can be seen in the GUI of Task scheduler but you cannot create and modify them there. However Task Scheduler tasks are not visible using the AT command.


--------------------- End of Document ----------------------------

Tags: Windows Server 2000, Windows Server 2003

Published Date: 20070822

Wednesday, August 1, 2007

Drives mapped using Startup script or schedule task are not available.

Here are the steps to reproduce.

  1. Map a network share to a drive letter using schedule task that fires at System Startup.
  2. Using the same login credentials create another schedule task to copy a file from local drive to the mapped drive.
  3. Set the above schedule task to fire at any specific time.
  4. The 'copying' task would not be able to see the mapped drive. Although both the schedule tasks are running with the same login credentials.

The above is also true for Windows services. Mapped drives are not available to windows services, so it is best to use UNC paths in Windows service code, if required.

The following MS article explains this behavior.

"-In Windows 2000, mappings to specific drive letters are globally accessible as long as the ID used has appropriate permissions." "-In Windows 2003, each individual login session has its own individual drive mappings that are not accessible to other users OR even to the same user in a different login session. In this case, one session is invoked by the first scheduled task, and another by the second, so they would not be able to share the drive mappings."

"On Windows NT and on Windows 2000, drive letters are global to the system. All users on the system share the letters A-Z. Each user does not get their own set of drive letters. This means a user can access the redirected drives of another user if they have the appropriate security access."

-------------------End of Document -------------------------

Tags: Windows Server 2000, Windows Server 2003

Published Date: 20080801