it-admin

Recover passwords on Windows XP or Server 2003 machines
By Bryan Muehlberger

Did you know that recovering a lost password for a local account on a
Windows XP (Professional or Home Edition) or Windows Server 2003 machine
is now possible with a new feature called the Forgotten Password Wizard?
This lightly publicized feature of Windows XP and Server 2003 may make
your job as an administrator a little easier.

Before this new feature can be useful, you must create a Password Reset
Disk (PRD) before you forget the password. To create the PRD, you can
open the Forgotten Password Wizard by pressing CTRL-ALT-DEL, selecting
Change Password from the Windows Security dialog box, and then pressing
the Backup button. Note however that the Backup button is only available
if you select the local machine from in the "Log on to" drop down box.
This also means that you can only create a PRD for local account (such
as Administrator), and not for domain accounts. Domain accounts still
require administrative rights in the domain to reset the password.

After you have launched the Forgotten Password Wizard, follow the
on-screen prompts that will walk you through the process. In less than a
minute, you will have your PRD successfully created.

Make sure that you store the PRD in a safe place. I would recommend a
locked safe or secure area where other items such as this are stored. If
someone gains access to the diskette, knows the machine for which the
account belongs, and knows which account the diskette is for, then they
have the ability to reset the password and break into your system.

Using the diskette is as easy as forgetting your password. When
attempting to logon with a bad password, Windows will prompt you with an
option to use a reset disk. By selecting this option, you will launch
the Password Reset Wizard, which will prompt you for your PRD. After the
wizard completes, the password has been reset.

There are a couple of things that you need be aware of:

1)The PRD can be used even if you change the password
multiple times, without having to update the PRD.

2)Use the latest service pack with Windows XP. If you don't have the
latest service pack, you may run into issues when you attempt to decrypt
files that were encrypted using Microsoft Encrypting File System (EFS)
prior to resetting your password with the Password Reset Disk. This is a
known issue and Microsoft has some KnowledgeBase articles that discuss
this in more detail.


--------------------------------------------------------------------------------

Scripting for Windows system administrators
By Bryan Muehlberger

As a Windows system administrator, you constantly perform many routine
tasks in an effort to manage, maintain, and support your Windows
environment. Occasionally the need will arise to create a script that
handles a repetitive task in a more efficient way, or gets a piece of
information that otherwise would be difficult to find out.

It is relatively easy to write scripts with the scripting technologies
that Microsoft provides. But if you are like most of us, taking the time
to learn all of the facets of a scripting language and the underlying
system requirements is difficult.

In this series of articles, I will provide you with a foundation upon
which you can successfully develop your scripting skills, and begin
writing scripts with a minimal amount of effort and time on your part.

Let's start with an overview of the different scripting technologies
that Microsoft has provided, and then in the weeks to come, I will touch
on each of the technologies in detail, and provide some basic code
snippets, along with links to where you can find more detailed
information.

Microsoft has created four independent, yet highly integrated components
that make up a well-rounded set of scripting technologies. These
include the Windows Scripting Host (WSH), Visual Basic Scripting Edition
(VBScript), Windows Management Interface (WMI), and Active Directory
Scripting Interface (ADSI). When combined, these components make up a
rich set of tools for developing basic to advanced administrative
scripts.

Each of these technologies provides you with different tools to develop
scripts:

* Windows Scripting Host (WSH) is the scripting engine that creates an
environment upon which scripts can execute on a Windows system.

* Visual Basic Scripting Edition (VBScript) is the scripting language,
based upon the Visual Basic framework, that actually provides the syntax
and program control that you will require within your script (i.e.
looping, if-then-else statements, function declarations, variable
storage, arrays, etc)

* Windows Management Interface (WMI) provides you with a consistent way
to access comprehensive system management information (i.e. hard drive
information, file system control, etc.)

* Active Directory Scripting Interface (ADSI) is the technology that
allows you to create scripts to administer directories such as Active
Directory.

Each of these technologies is very important when it comes to systems
management, but the two most important pieces are VBScript and WSH,
because without these two components, you would not be able to take
advantage of the features of WMI and ADSI (see Figure 1).

Figure 1
http://itw.itworld.com/GoNow/a14724a73317a97736788a3


--------------------------------------------------------------------------------

Determine directory resource usage with diruse.exe
By Bryan Muehlberger

Recently we needed to identify home directories on our file servers that
exceeded expected usage guidelines. Our servers are structured in such a
way that all of the home directories are named the same as the owner's
username. As a result, once we identify how much disk space a particular
directory consumes, we can easily identify the data's owner and correct
the problem.

To accomplish this, we needed a utility that allowed us to query the
size of a single folder's contents as well as its corresponding
subdirectories. During our search, we discovered a resource kit utility
called diruse.exe, which allows an administrator to query folders on a
Windows server to get the the content size. This utility is part of the
Windows 2000 Resource Kit, and can be downloaded from Microsoft at:

http://itw.itworld.com/GoNow/a14724a73074a97736788a0

The utility has a number of useful options available that make reporting
very easy. We used a command similar to the following:

diruse.exe" /* /M /, \\serverName\Share
In my example, the subdirectories under the share are all of the user's
home directories and look like the following:

\\serverName\Share\username1\\serverName\Share\username2\\serverName\Share\username3
By running the utility, I get an output that looks similar to the
following:

Size (mb) Files Directory
200.23 764 SUB-TOTAL: \\serverName\Share\username1 253.32 7902 SUB-TOTAL: \\serverName\Share\username2 153.70 838 SUB-TOTAL: \\serverName\Share\username3 .

By forcing the output to dump to a log file (i.e. using stdout
redirection 'command > logfile.txt'), I am able to open the output file
in Excel and sort by size. This allows me to narrow down the list to the
top users and handle them accordingly.

We typically look for users that exceed 2G-bytes of file server usage
within their home directory. After we get through these "high-end"
users, we target other categories of users.



--------------------------------------------------------------------------------

Learn to use Windows File Protection - part 2
By Bryan Muehlberger

Last week we talked about the Windows File Protection (WFP) service and
the associated utility System File Checker (SFC) utility. The SFC
utility is part of the Windows 2000/XP and Server 2003 platform and must
be used in conjunction with the WFP service. This week we'll discuss
some of the associated registry settings and command line parameters
that allow you to optimize and better control the functionality of the
SFC utility.

One of the most important components of the SFC utility is the DLLCache
folder. This folder contains the verified (via driver signing) system
files that your system maintains. If this folder becomes corrupt, you
can run "sfc /purgecache". This purges the existing, but corrupted
DLLCache folder and automatically begins a scan of the system.

Some administrators may want to control what files are contained in the
DLLCache folder. This may be necessary in an FDA-qualified environment
at a pharmaceutical or healthcare organization. To maintain a copy of
the DLLCache folder on shared network share for all users, you must
modify the following registry key on all of the machines that you want
to be using the shared location:

Location: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon
Key = SFCDllCacheDir (REG_EXPAND_SZ)
Path = local or network location of the Dllcache folder (default is the
%SystemRoot%\System32\Dllcache folder)

NOTE: Modify the registry at your own risk. Incorrect modifications
can cause your system to fail.

The only caveat to doing this is that if a machine cannot access the
shared folder (i.e. a laptop user who is traveling), then they will not
be able to run the SFC utility until they are connected to the LAN
again.

Another useful registry setting is the SFCShowProgress registry key:

Key = SFCShowProgress (REG_DWORD)
0 = Do not display the System File Checker progress meter (default)
1 = Display the System File Checker progress meter

This registry setting allows you to show a progress meter while SFC is
running so that you know its status.

Last, due to the number of system files that WFP is monitoring for you,
you may want to increase the size of the DLLCache folder. You can do
this by setting the registry key:

Key = SFCQuota (REG_DWORD)
n = size (in megabytes) of the Dllcache folder quota
ffffffff = (default) cache all protected system files on the local hard
disk

The default size of the DLLCache folder is approximately 250M-bytes.


--------------------------------------------------------------------------------

Windows scripting host: Wscript vs. Cscript
By Bryan Muehlberger

Last week, I introduced you to a core component of the Windows Scripting
Technologies platform called the Windows Scripting Host (WSH). WSH is
included with Windows 98, Windows 2000, Windows XP and Windows Server
2003. However, each operating system came with a different default
version of WSH, ranging from version 1.0 to its current version of 5.6.
Depending upon the version you have installed on your system will
determine the features that are available to your scripts. To see a
comparison of the different versions of WSH check out:

http://itw.itworld.com/GoNow/a14724a74338a97736788a0

Please note that I will assume you are using WSH version 5.6 in my
discussions (to determine which version you are running, type cscript at
the command prompt)

This week we continue our discussion of WSH and discuss the two
different hosting environments provided to you by WSH - Wscript and
Cscript.

Both Wscript and Cscript are part of the WSH environment, but each
provides you with a different experience when executing your scripts.

Wscript is the GUI version of WSH. Most Windows operating systems
default to using Wscript when executing a script. Therefore, if you
double click a .vbs script, most likely it will run using the
wscript.exe version of WSH. This will send all output directly to the
screen in the form of message boxes. Alternatively, you can force the
use of Wscript by typing the following in a command prompt window:

Wscript.exe scriptName.vbs

On the other hand, Cscript is the command-line version of WSH. Cscript
allows slightly more control over your scripts and is typically the
preferred method for administrative scripts. You can use Cscript by
typing the following at the command prompt:

Cscript scriptName.vbs

Using Cscript causes all output to be sent to the command prompt window,
thus allowing you more control over the output, and prevents you from
having to respond to every message that is displayed (which is the case
when you use Wscript).

Both Wscript and Cscript come with a number of options. You can display
these options by typing wscript or cscript at the command prompt.

Next week we will begin our discussion Visual Basic Scripting Edition
(VBScript).

--------------------------------------------------------------------------------

Introduction to Windows scripting host
By Bryan Muehlberger

Windows Scripting Host (WSH) is the scripting engine that creates an
environment upon which scripts can execute on a Windows system. The key
here is that WSH "creates the environment" that allows your scripts to
execute on a Windows system. It is included by default on Windows 98,
ME, 2000, XP and the soon to be released Windows Server 2003. However,
different versions of WSH are included with each platform. You can find
out more about the different versions at:

http://itw.itworld.com/GoNow/a14724a73874a97736788a1

In the most simplistic way, WSH makes certain objects and services
available to your scripts. These objects and services allow your scripts
to map drives, modify the registry, print messages to the screen, and
many other things. Generally, scripts are written in either Jscript or
Vbscript, but throughout this article series, we will concentrate on the
Vbscript scripting language for our sample scripts.

To create a script that runs within the WSH environment, you need to
create text file and utilize the appropriate extension:

.VBS for VBScript
.JS for JScript

The contents of the script file will include your script code written in
either the Jscript of VBScript syntax (which we will discuss in future
articles).

For example, let's make a simple "Hello World" script. You would need
to create a text file and add the following lines to it:

Wscript.echo ("Hello World")

Then save the file as helloWorld.vbs. Now if you double-click the file
it will process the script using the VBScript scripting engine (because
of the .vbs extension) and process the WSH echo command which will
create a message box saying "Hello World". However, what if your script
is writing tons of information to the screen? This would cause you to
have to click OK to every message - which could be quite inconvenient.
There are other options though. This brings us to the topic of
cscript.exe versus wscript.exe, which we will talk about next week.

Next week we will take a more in depth look at the WSH and Cscript.exe
Veruse Wscript.exe.

Part 1: Scripting for Windows system administrators
http://itw.itworld.com/GoNow/a14724a73874a97736788a3