3 Ways to Enable the Built-In Windows 7 Administrator Account

In Windows 7, like Windows Vista, when you install the operating system, you are asked to enter a user name which will be the primary local user that will use this system.

Like in Windows Vista, in Windows 7 the built-in Administrator's account is disabled by default. Furthermore, this account is not associated with any password.

The new user which is created during the installation is configured to be a member of the built-in Administrators group, and in fact, can be used for any management task. That use is in fact equivalent by all means with the original built-in Administrator account.

However, there may be situations where one would like to use the built-in Administrator account instead of that "new" user. One of these might be when you're building a system for cloning purposes, and would like all cloned machines to be able to use the built-in Administrator's account.

Note that since that account does NOT have a password, enabling it without properly setting a password for that account will open a serious security opening on your system!

There are basically 2 easy methods of enabling the built-in Administrator's account and 1 advanced method.

Method #1 - Using the Local Users and Groups Snap-in

To enable the built-in Administrator's account by using the Local Users and Groups snap-in please follow these steps:

Open Local Users and Groups. You can do so by typing lusrmgr.msc in the Start search box or in the Run command and pressing ENTER. Or, you could open Computer Management by right-clicking Computer in the Start menu and selecting Manage.

Expand System Tools > Local  Users and Groups > Users.

Right-click the Administrator account and select "Set Password".

In the"Set Password for Administrator" click "Proceed".

In the"Set Password for Administrator" enter the Administrator's desired password twice, and click "Ok".

Next, enable the Administrator's account. Right-click the Administrator's account and select "Properties".

Un-chek the "Account is disabled" check-box. Click on the "Ok" button.

Administrator's account is now enabled and configured with a password.

Method #2 - From the Command Prompt

To enable the built-in Administrator's account by using the Command Prompt  please follow these steps:

1. Click Start and type CMD, then press Enter. It is best to run the Command Prompt as an Administrator. To do so, right-click CMD and select "Run as Administrator".

When prompted to allow the Command Processor to run, click on "Yes".

BTW, you can also hover over the CMD line and press CTRL + SHIFT + ENTER to invoke the "Run as Administrator" shortcut.

In the Command Prompt window, type:

net user

Note how the Administrator account is there, yet the new user account has not been yet created.

To set the Administrator's account password:

net user *

Then enter the required password and confirm it.

To enable the Administrator's account:

net user administrator /active:yes

Method #3 (Advanced Users) - During the Installation Process

There is a 3rd method which advanced users can use. This method can be used during the installation process itself.

During the installation, after being prompted to configure the new user account, you will be able to set the new account's password.

At that phase, press SHIFT and F10 keys together. A Command Prompt window will appear.

In the Command Prompt window, type:

net user

Note how the Administrator account is there, yet the new user account has not been yet created.

To set the Administrator's account password:

net user *

Then enter the required password and confirm it.

To enable the Administrator's accoun:

net user administrator /active:yes

Close the Command Prompt window and continue with the installation process.

If you log off you will now see the Administrator's account as a valid logon option.

Join a Domain in Windows 7

Joining your machine to a domain will let you enjoy the domain's benefits, such as scalability, central management, Group Policies, security and more.

Prerequisites

Before joining your Windows 7 machine to a domain, make sure you properly understand the following prerequisites:

Use Windows 7 Professional, Ultimate or Enterprise - Only Windows 7 these editions can join a domain. No, Windows 7 Home can't. Don't try it.

Have a  network Interface Card (NIC) - Duh, but unless you have one (or a wireless connection) how do you expect to connect to the server?

Be physically be connected to the LAN - Windows 7 (and previous OSs) has an LAN auto sensing feature. Whenever you disconnect from the network, a balloon appears in the tray area notifying you of the disconnection status. Note that Windows 7 can be joined in an offline mode to a Windows Server 2008 R2 domain, but that's a topic for a different article.

Have a valid IP address - Valid for the network you're connected to. You can either configure one manually, receive one from a local DHCP Server, or leave it as is and receive an APIPA address (whatever starts with 169.254.X.Y). If it's an APIPA address you're asking for potential problems, as APIPA and AD do not go together hand-in-hand.

Have all-time connectivity to the Domain Controller - Or at least one of them. The IP address you've configured (or leased) should be good enough to enable you to connect to one of the Domain Controllers on your Domain. You may test your connectivity with PING, but make note that a successful PING does not guarantee that you've got proper connection to the DCs.

Have a properly configured DNS server - Without a properly configured DNS server your workstation will not be able to connect to the domain. Even if it did (for example you had a working DNS server but you somehow messed it up or shut it down) it will take a lot of time to actually log-on, and many AD related administration tasks will not work. The DNS server must hold a zone with the exact name of the AD domain you're trying to join. It also must hold 4 SRV folders (you can tell by the "_" in their name). If it doesn't, you either misspelled the domain name or DNS zone, or the zone is not configured to accept dynamic registrations, or it's not a Windows 2000/2003/2008 DNS server, or the Domain Controller does not have a working connection with the DNS server (firewall problems, improper IP configuration, IPSec etc.)

Have all-time connectivity to the DNS server - Test your connection to the DNS server by PINGing it and performing an NSLOOKUP query.

Possess local Administrative power - A simple user won't do. You must be the local Administrator.

Know the correct domain name, Administrator's name and password - Misspelled your domain name? You won't get to the Username and Password prompt!

Got your domain name right? You'll be asked for a valid username and password. To be safe, enter one that has Domain Admins rights, although you could get away with less, depending on your AD configuration (by default, any domain user has the right to join up to 10 machines to the domain. But this setting may have been altered by the domain admin).

You can perform the preceding tasks by using the Computer Name tab in the System Properties dialog box from the Control Panel or by right-clicking My Computer, and then Properties or by pressing the Windows logo key and Break. You may also use the NETDOM command. I will cover both methods.

Method #1 - The Traditional Way

1. Open System by clicking the Start button, right-click "Computer", and then click "Properties".

2. Under "Computer name, domain, and workgroup settings", click "Change settings".

Actually, you can also click on "Advanced system settings" and click on the "Computer Name" tab.

A third method to get to the same place is to use the Control Panel. Type "Domain" in the search box, then click on "Join a domain" link.

Either way, you're there. If you're prompted for an administrator password or confirmation, type the password or provide confirmation.

3. Click the Computer Name tab, and then click "Change".

4. Under Member of, click Domain.

5. Type the name of the domain that you want to join, and then click OK.

You will be asked to type your user name and password for the domain.

Once you are successfully joined to the domain, you will be prompted to restart your computer. You must restart your computer before the changes take effect.

Alternatively, you can click "Network ID" to use the Join a Domain or Workgroup wizard to automate the process of connecting to a domain and creating a domain user account on your computer. This is a longer way and I'm not sure why people would want to use it, but I'll document it anyway.

Go through the steps of the wizard. Make sure you select "This computer is part of a business network".

Then select "My company uses a network with a domain".

Provide the domain name and proper credentials.

And again.

You will still need to restart when the wizard is done.

Method #2 - Using NETDOM

By using NETDOM you can accomplish the task of joining a domain from the command prompt, and do it all in one line.

NETDOM is now included in the core OS, unlike Windows 2000/XP/2003 where you had to install the Support Tools to get it.

Open a Command Prompt window with Administrative credentials and type the following line:

Notes: Replace DOMAIN.COM and DOMAIN with your correct domain name, and of course, enter the proper user credentials. Also note there's an additional "d" in "user" and "password", that is NOT a typo.

netdom join %computername% /domain:DOMAIN.COM /userd:DOMAIN\administrator /passwordd:P@ssw0rd

Reboot the computer to complete the process.

List all Users and Groups in Domain

There are many tools and utilities designed to do so, but none are native W2K GUI. There are no graphical or command line utilities that produce comprehensive reports on groups, users and permissions included with the Windows Operating System or the Resource Kit. The NET commands and the Windows Resource Kit ADDUSERS.EXE and PERMS.EXE utilities can be used to create limited administrative reports by piping the output to a text file.

Limited report generation is possible through the following commands:

Note: Removal of the /domain switch will generate a report for the local machine.

NET USERS /DOMAIN >USERS.TXT

This command will return the user accounts from the Primary Domain Controller (PDC) of the current domain, and write them to a file called USER.TXT

NET ACCOUNTS /DOMAIN >ACCOUNTS.TXT

This command will return the account policy information from the PDC of the current domain, and write it to a file called ACCOUNTS.TXT

NET CONFIG SERVER >SERVER.TXT

This command will return the server name, version of Windows, active network adapter information/MAC address, Server hidden status, Maximum Logged On Users, Maximum open files per session, Idle session time, and assign it to a file called SERVER.TXT

NET CONFIG WORKSTATION >WKST.TXT

This command will return the workstation name, user name, version of Windows, network adapter, network adapter information/MAC address, Logon domain, COM Open Timeout, COM Send Count, COM Send Timout, and write it to a file called WKST.TXT.

NET GROUP /DOMAIN >DGRP.TXT

This command will return the global groups on the PDC of the current domain, and write them to a file called GRP.TXT.

NET LOCALGROUP >LGRP.TXT

This command will return the local groups on the local machine, and write them to a file call LGRP.TXT.

NET VIEW /DOMAIN:DOMAINNAME >VIEW.TXT

This command will return the resources in the specified domain, and write them to a file called VIEW.TXT.

Using Resource Kit Tools

ADDUSERS \\COMPUTERNAME /D USERINFO.TXT

This Windows Resource Kit command will return a comma delimited file (for spreadsheets) containing user and group information, and write it to a file called USERINFO.TXT.

PERMS COMPUTERNAME\USERNAME C:\*.* /S >PERMS.TXT

This Windows Resource Kit command will return the username permissions on all files in all subdirectories on the c:\ drive of the computername, and write it to a file called PERMS.TXT

In addition to these user management tools, there are many tools and scripts out there to help in querying, creating, modifying and deleting user objects in the directory. You should explore the Support Tools from the Windows 2000 product CD and the Windows 2000 Resource Kit to get acquainted with some of them at least, since they can really ease your work sometimes. Here is a quick description of some of those tools:

The Windows 2000 Resource Kit offers us some scripts for handling users:

ClassifyMembers.vbs

Will list objects in a container/OU or a domain.

ListProperties.vbs

This script can be used with the WinNT:// namespace against Windows NT, Member or Workstation machines, or with the LDAP:// namespace for Active Directory Domain Controllers. Pay attention that this script is case-sensitive in its syntax.

As for enumerating group membership, there are several tools, such as:

FindGrp.exe IfMember.exe ShowGrps.exe

Each gives different results, so you might want to run them and compare the outputs of each tool. ShowGrps.exe, for example, can also query for group membership of computer objects:

FindGrp.exe <Domainname>\<MachineName>$

If you want to search for users satisfying a given criteria, you can try out

chkusers.vbs

This script checks your domain for users that satisfy a certain criteria that you define. For example:

Cscript CHKUSERS.VBS /A:WinNT://YourDomainName /P:FullName;Description /C:"((LastLogin:>4/3/01 or LastLogin:<8/4/01) and AccountDisabled:=False)"

This will output the full name and description of all active users whose last login was between 4/3/01 to 8/4/01.

Using LDIFDE

From the support tools we can find LDIFDE.exe, which is a tool for bulk import and export of Active Directory Objects. You can use LDIFDE to import new user records into the directory, or export specific information on specific users into a text file. LDIFDE defaults to export mode (reading From the Directory). When you add the -i option it can be used to write changes into the Directory. Also, if you want to export and extract only specific details, such as the user name, title and login name for all the users in a specific OU (Organizational Unit), you can run the following command:

ldifde -f C:\ldif\ExportUsers.ldf –s SERVERNAME -d "OU=YourOUname,dc=YourDomainName,dc=com" -p subtree -r "(objectClass=User)" -l "cn,givenName,Title,SamAccountName"

Remotely Manage Devices in Windows 2008 Server Core

Server Core installation provides a minimal environment for running specific server roles, which reduces the maintenance and management requirements and the attack surface for those server roles. You can read more about Server Core in the "What's Related" section at the bottom of this page.

Getting to the point of this article, remotely managing Server Core is not as hard as it seems. You can read more about it on several of my articles, but the point is that most things can be done remotely by using the regular MMC-based snap-in Administration tools, WinRM and WinRS, and even through Remote Desktop.

This article focuses on remote administration via the MMC-based Administration tools. In order to get these to work across the network you will need to run the following command on the server core machine (or on any other Windows Server 2008 server for that matter):

netsh advfirewall firewall set rule group="remote administration" new enable=yes

The above command will allow for most remote management tools to work out-of-the-box. However, in addition to allowing the MMC snap-ins through the firewall, using Device Manager remotely requires additional configuration. If you don't perform the following steps you will end up with this error:

Running Device Manager remotely

To allow Device Manager to connect to a remote computer, you must first enable the "Allow remote access to the PnP interface" setting on the target computer's Local Group Policy.

1. On a Windows Vista or Windows Server 2008 installation, start the Group Policy Object MMC snap-in by typing MMC in the Run box and pressing Enter.

2. In the Add or Remove Snap-Ins window, scroll to find Group Policy Object Editor, and click Add.

3. In the Select Group Policy Object window, click Browse.

4. In the Browse for Group Policy Object window, click Another Computer, and either type or browse for the remote server core machine.

5. In the Select Group Policy Object window, click Finish.

6. In the Add or Remove Snap-Ins window click Ok.

7. In the Group Policy of the remote computer, navigate to Computer Configuration -> Administrative Templates -> System -> Device Installation.

8. Enable the Allow remote access to the PnP interface setting.

9. Close the MMC console (you don't have to save it, but you can if you want to).

10. Restart the Server Core installation.

Now you can connect to the remote server core machine and manage its devices by using Device Manager.

1. Open Computer Management through the Administrative Tools folder.

2. Right-click Computer Management and select Connect to another computer.

3. In the Select computer window, type or browse to the remote server core computer. Click Ok.

4. Expand System tools -> Device Manager. Note that now you can perform changes on the listed devices.

And that's it! You are done!

Plan your Exchange 2007 Backups based on Server Roles

When Microsoft created Exchange Server 2007, one of the biggest
changes that they made was the creation of server roles. The concept
of roles existed in Exchange server 2003, it was very limited. In
Exchange server 2007, there are five different roles which serve five
very specific purposes.

Because these roles are so different from one another, the tasks that
an Exchange Server performs, and the code that is installed is
entirely dictated by the role that the server is configured to
perform. That being the case, it is necessary to completely reevaluate
your backup strategy. The backup techniques and procedures that
Exchange admins have used for so long are not always the best option
in an Exchange Server 2007 environment. In this article, I will
discuss some backup strategies for each of the various Exchange 2007
server roles.
Mailbox Server

Like its predecessors, Exchange Server 2007 stores user's mailboxes in
a jet database (now called an extensible storage engine database). For
all practical purposes, backing up a mailbox server in Exchange Server
2007 is really no different than backing up an Exchange 2003 server.
That being the case, I want to focus the majority of my discussion on
the other server roles.
Hub Transport Server

As I'm sure you probably know, a hub transport server's primary job is
to route messages within the Exchange Server organization. At first
glance, it would appear that it would be appropriate to use the same
backup technique for a hub transport server as you would use for a
mailbox server. After all, a hub transport server contains all of the
message queues, and then Exchange Server 2007, the queues are based on
a jet database that is very similar to the ones used by mailbox
servers.

In spite of this though, Microsoft actually recommends that you do not
backup hub transport servers in the traditional manner. This is
primarily because of the transient nature of the messaging queues.
Suppose for a moment that you made a backup of the hub transport
server, and 15 minutes later the server failed catastrophically. It
wouldn't really do you any good to restore the database used by the
message queues, because all of the messages that were in the queues at
the time that the backup was made would have already been delivered.

Not only is it not necessary to backup the message queues, you really
don't have to worry about backing up the server's configuration
either. The vast majority of the configuration information is stored
in Active Directory. If you find yourself having to rebuild a hub
transport server, you can simply run Setup with the
/Mode:RecoverServer switch. This command will use information
contained in the Active Directory to rebuild the server. You can read
more about this command at Microsoft Technet.
Edged Transport Servers

Although it's transport servers are designed to be isolated from the
rest of your Exchange Server organization, they are architecturally
very similar to hub transport servers. In fact, it's transport servers
use queues that are based on the extensible storage engine just like
hub transport servers do. Like hub transport servers, it is
impractical to try to back up these queues.

Assuming that you are running a default configuration, you may not
even need to worry about backing up an edge transport server. After
all, Microsoft automatically updates the ant spam information over the
Internet.

There are two cases though that weren't backing up an edge transport
server. One such situation would be cases in which you want to retain
your message tracking and protocol logs. If you need to back up these
logs, you can perform a simple file level backup. Incidentally, the
same thing goes for hub transport servers.

The other situation that would warrant backing up an edge transport
server is that you would want to create a backup if you were using
custom filtering settings. If you are using custom filtering settings,
you'll have to use a predefined script to export those settings to an
XML file. You can then back that XML file up using a normal file level
backup. Should you ever need to restore the settings, you simply
import the XML file using another predefined script. In case you're
wondering, these scripts are called ExportEdgeConfig.ps1 and
ImportEdgeConfig.ps1. Both of these scripts are located in the
\Program Files\Microsoft\Exchange Server\Scripts folder.
Client Access Servers

Backing up and restoring client access servers can be pretty tricky.
Like a hub transport server, you can rebuild a client access server by
entering the SETUP /MODE:RecoverServer command.

The problem is that entering this command returns the client access
server to a default state. Even if you have created non-default
virtual directories, those directories will be wiped out after using
this command. Unfortunately, entering this command and then restoring
a backup isn't really an option because doing so will cause the IIS
Metabase to be out of sync with the Active Directory. As such,
Microsoft recommends that you make a log of all of the custom changes
that you apply to your server. You can use the Setup command to
rebuild the server, and then manually reapply your customizations.

If you decide to perform a traditional backup, then you must design
the backup to include system state data.
Unified Messaging Servers

As I'm sure you probably know, unified messaging servers allow you to
store voice mail and faxes in Exchange Server mailboxes. Assuming that
your unified messaging server is running a default configuration, you
don't have to worry about backing it up. All of the essential
configuration data is stored in the Active Directory, and you can
easily rebuild a unified messaging server by using the SETUP
/MODE:RecoverServer command.

There is one exception to this rule though. If you have configured
your unified messaging server to use custom voice prompts, then you
will need to perform a file level backup to ensure that those voice
prompts are backed up. In case you're wondering, voice prompts are
stored in the \Program Files\Microsoft\Exchange Server\Unified
Messaging\Prompts folder.

How to Plan SQL Server Database Files

One of the most important tasks you can do in SQL Server is to setup
your data and log files. Not getting these files setup correctly can
be one of the biggest causes for production problems whether it's disk
contention, space usage, or something else. And honestly this level
of planning is often overlooked and by the time the problem is
discovered the application and its users have already suffered. So
let's get into some good discussion about how to setup your database
files.

Log files

We're going to start with logs first because they're the easiest and
probably the ones you'll touch most frequently. And we need to talk
about placing your log files on disk first. In general, you'll want
to place your log files on a different physical partition than your
data files. This is for 2 reasons. The first is disk contention.
Every transaction has to write something to the log file before it can
write it to the data file and if both files are on the same disk, then
the disk arm has to work twice has hard because it has to jump over
here to write the log and then jump over there to write to the table.
Putting a log file on its own disk is also better for the performance
of the log because logs write sequentially so if the log file is on
its own disk the disk arm has very little moving to do to get to the
next place it needs to write so it's much faster. The second reason
you want data and log files on separate disks is for recovery. If the
data partition fails you'll want the log on a separate set of disks so
you can still recover the logs and roll the last transactions forward
so you don't lose any data.
Several log files

It's a common misconception that you will get a performance gain by
using several log files. This is something we see quite often and it
simply isn't true. Log files are written sequentially which means
that each log file is filled up before the next one is written to. So
if you have 4 log files (Log1, Log2, Log3, Log4), SQL Server 2008 will
fill up Log1, then fill up Log2, etc. This is different from the way
data files behave and we'll discuss that in a minute. The only reason
to have multiple log files on multiple partitions is for space. You
may need more disk than a single partition can provide. Oh, and
putting multiple log files on a single partition is just dumb. It
gains you nothing.
Data files

Now let's talk about where you'll place your data files. As we've
already said it's a good idea to place them on a different physical
partition from your log files. And we know we already said that, but
experience has shown us that we could fill an entire page with that
exact advice and a good portion of you still won't grasp the
importance of it. So we're really going to hammer that point home in
this article.

So while your data files are separated from your log files you may
feel free to have multiple data files on multiple physical partitions
to take advantage of performance gains. Now, we have to say again
that these have to be physical partitions because logical partitions
are still on the same physical disk and it's the disk arm contention
you're trying to avoid. Data files, unlike log files, use what's
known as an equal fill algorithm. This means that all of the files
are filled equally as much as possible. So let's say you have 4 data
files (Data1, Data2, Data3, Data4). When you write to the database,
SQL Server 2008 will write to these files in a round robin fashion and
they should grow at more or less the same rate. You can also place
tables inside specific files so you have a good level of control over
how you split up the I/O workload in your database. And while the
number of files you need to optimize your workload is a subject that's
up for debate in the community, for most systems it won't make that
much difference. However, it is a good idea that no matter how many
data files you decide to have, to make them all the same size. This
goes back to that equal fill algorithm we were talking about before.
File growth

Another good topic is file growth. This is a mistake that many
beginners make. They accept the defaults for file growth and that's
just asking for trouble. We're going to give you some advice on how
to set your file growth and you can adjust it to suit your needs, but
at least you'll know the arguments.

1. The best thing to do is to set both your data and your log files
as large as you ever want them to be. Depending on your version of
SQL Server, it can be very expensive to grow files so setting their
size ahead of time can alleviate performance problems before they even
start. So if you've got a single partition dedicated to your log
file, then go ahead and make your log the same size as your partition.
If it's dedicated then you've got nothing to lose. And the same goes
for your data files. If they're on dedicated partitions (and they
should be), then you've got nothing to lose.
2. The next best thing is to set your files to autogrow by fairly
large predictable increments. The default autogrowth is 1MB for data
files and 10% for log files. I always grow data files by at least 1GB
and often times even more. If you're going to suffer the expense of
growing a file you don't want to do it 5 times a day, so make it worth
your while. And 10% is too unpredictable. As the log grows the 10%
marker is going to get bigger too so you'll actually be growing your
log more and more each time.
3. Set all your data files to grow at the same rate, and all of
your log files to grow at the same rate. Your data files don't have
to grow at the same rate as your log files, but they should grow at
the same rate as each other.

Here we talked about separating your data and log files onto separate
partitions, as well as some of the theories on why we recommend the
things we do. In the next article, How to manage SQL Server database
files, we'll talk about how to physically change your file properties
to accomplish these goals. And don't forget to separate your data and
logs onto separate physical partitions.

Working with Domain Member Virtual Machines and Snapshots

One of the benefits of using a virtualization product that allows you
to create snapshots, is the ability to create a "point in time" to
which you can always revert your virtual machines. By reverting to
this snapshot, you get your VM to the state in which it was saved, and
are able to perform various tasks such as testing software, doing QA,
creating labs and so on.

However, one of the nasty issues of working with snapshots is when you
have one or more virtual machines that are members of an Active
Directory domain. When you create snapshots of such machines and
restore them, you might occasionally find that all authentication
involving the VM seem to fail, and face an issue of not being able to
log on to the virtual machines, or not being able to access files and
shares across the network. You might even get errors like this one:

Windows cannot connect to the domain, either because the domain
controller is down or otherwise unavailable, or because your computer
account was not found. Please try again later. If this message
continues to appear, contact your system administrator for assistance.

If you log on locally (not using a domain account) to the computer
(in this example it's a Windows XP Pro client), you'll see the
following events in the Event Viewer.

NETLOGON 3210

This computer could not authenticate with
\\WIN2003-SRV1.petrilabs.local, a Windows domain controller for domain
PETRILABS, and therefore this computer might deny logon requests. This
inability to authenticate might be caused by another computer on the
same network using the same name or the password for this computer
account is not recognized. If this message appears again, contact your
system administrator.

LSASRV 40961

The Security System could not establish a secured connection with
the server cifs/WIN2003-SRV1.petrilabs.local. No authentication
protocol was available.

W32Time 18

The time provider NtpClient failed to establish a trust
relationship between this computer and the petrilabs.local domain in
order to securely synchronize time. NtpClient will try again in 15
minutes. The error was: The trust relationship between this
workstation and the primary domain failed. (0x800706FD)

And possibly others.

This is nasty, however, if you carefully remember the days when Ghost
was the only way to image a computer, you might also remember that it
was always a good practice not to "ghost" a machine that was a member
of a domain, and that if you didn't do that, you ended up with a
cloned computer that was "ghosted" back from an image, and that, in
some cases, could not log on to the domain it was a member of. So this
is not a new situation, it's just the new "ghosting" tools we're
using.

The reason for this is that there is a computer account password
mismatch. The Windows-based domain member VM thinks that its machine
account password is something X, while the domain controller believes
it to be something Y. Because of this, the VM cannot authenticate
itself to the domain controller(s).

So how does this work? Just like user account passwords, computer
account password is a "secret" that is set up by the computer account,
and that is used when a Windows-based domain member computer
authenticates itself to the domain controller and establishes a secure
channel.

When the computer is started, a service called NetLogon uses the
machine account password and tries to establish a secure session with
the domain controller. The usual CTRL+ALT+DEL Winlogon process also
relies on this authenticated secure channel to send user credentials
to the domain controller for verification and log them into the
computer. Other services running on this machine that work with the
LocalSystem or NetworkService credentials also require this
authenticated secure channel to get access to domain resources.

So without this proper password there cannot be a secure channel, and
hence the issues described above, and various things fail as a
consequence.

The password is first created when the computer is joined to a domain.
It is shared by domain controller and the computer.

So what happens during regular operations? Well, to explain this, we
need to think or 3 scenarios:

1. Regular operation, client computer works "regularly", never offline
for extended periods of time. Each Windows-based computer maintains a
machine account password history containing the current and previous
passwords used for the account. Regularly, the computer account
password change is initiated by the Netlogon service on the client
computer every 30 days by default . Since Windows 2000, all versions
of Windows have the same value. After this change, both the domain
controller and the computer use the new password for authentication.

When a client determines that the machine account password needs to be
changed, it would try to contact a domain controller for the domain of
which it is a member of to change the password on the domain
controller. If this operation succeeds then it would update machine
account password locally.

When two computers attempt to authenticate with each other and a
change to the current password is not yet received, Windows then
relies on the previous password. If the sequence of password changes
exceeds two changes, the computers involved may be unable to
communicate, and you may receive error messages.

2. Not-so-regular-operation but still possible, when a client computer
is taken offline for an extended period of time, 30, 60, 90 days or
more. In this scenario, if a computer is turned off for three months
nothing expires. When the computer starts up, it will notice that its
password is older than 30 days and the Netlogon service on the client
computer will initiate action to change it. This is only applicable if
the machine is turned off for such a long time.

3. Snapshots, when either a "Ghost"-type image or (related to this
article) a VM snapshot is taken, then the computer resumes regular
operation (as of scenario #1). Then suddenly, after working for 30,
60, 90 days or more, the snapshot is brought back. While using
snapshots, when the domain member is restored to an older snapshot, it
loses track of any password change changes done later and tries to use
an older password. Hence it fails to authenticate itself.

So how do you fix this? Well, first of all, if you've already gotten
to the point where the error occurred and you cannot log-in, you will
need to read my Fixing "Windows cannot connect to the domain, either
because the domain controller is down or otherwise unavailable, or
because your computer account was not found" Errors article for a
solution.

However, if you wish to prevent this from happening AND you're using
virtualization software and snapshots, you may want to do one of the
following:
Option #1

Increase the computer account password age, or disable password
changes altogether. Both these can reduce likelihood of the problem,
but may reduce the level of security in the domain. On the other side,
since this is probably a test, a QA or a demo environment, you may
consider it as a valid option . These settings are available on the
domain member (and not on the domain controller), and as such, you can
change them on your computer before you create a snapshot out of it.
Warning!

This document contains instructions for editing the registry. If you
make any error while editing the registry, you can potentially cause
Windows to fail or be unable to boot, requiring you to reinstall
Windows. Edit the registry at your own risk. Always back up the
registry before making any changes. If you do not feel comfortable
editing the registry, do not attempt these instructions. Instead, seek
the help of a trained computer specialist.

As noted above, these settings are configured on the domain member,
and are controlled by the Netlogon service. Settings are found in the
following Registry key:

HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters

DisablePasswordChange (default off) prevents the client computer from
changing its computer account password. To disable, give it a value of
1.

MaximumPasswordAge (default 30 days) determines when the computer
password needs to be changed. Change it to whatever number of days you
think may be enough. For example, if you use snapshots that are less
than 100 days old, then you can set this value to 100 or similar.

Settings can also be configured by using Group Policy (either
domain-based GPO or local):

Computer Configuration\windows Settings\Security settings\Local
Policies\Security Options

Domain member: Disable machine account Password changes

Domain member: Maximum machine account Password age

After making the changes, reboot the client computer(s), and then
create a snapshot, if you need one.
Option #2

Live with it, know it's an issue, fix it every time. It's time
consuming, sure, but it's probably more secure than option #1. Read my
Fixing "Windows cannot connect to the domain" Errors article.
Option #3

If these VMs are used for testing, QA, demos etc. you could consider
creating a "closed" environment, where not only the client computer
has a snapshot, but also the domain controller(s) have one. When you
revert to a snapshot, you also revert to the same snapshot level on
the DCs, all of them, at the same time. For some settings this may
actually be a nice setup. However, if you cannot create such a setup
then you're probably have to either go with option #1 or #2.

How to Install SQL Server 2008

SQL Server 2008 is relatively easy to install, but it does take a little knowledge of the process and a little planning.  For most shops the planning phase can be minimal but there will be instances (like clustering) when you'll need to plan quite a bit.  This will not be one of those cases.  Today we're going to discuss a straight-forward SQL Server 2008 install.  Unlike some of the other Microsoft products there are a lot of screens to go through when installing SQL Server 2008, but most of them aren't that bad.  You just need to know what choices to make.

Before we walk through the screens and the choices you'll be making, let's go over a couple things you're going to need to know before you get started.  First of all you need to make sure your system meets the minimum requirements for the version of SQL Server 2008 you're installing.  That really isn't very difficult these days but it's best to check anyway.  You can find a list of the minimum requirements here.

Assuming that you'll be installing this on a production system it's important to know that there is at least one system reboot required for this install.  That's because the first thing this install will do is upgrade your version of Windows Installer to 4.5.  If you've already got Windows Installer 4.5 then setup will not require the reboot.  Next it will install version 3.5 of the .Net framework.  On most boxes this shouldn't require a reboot.  I tell you this because if you're installing SQL Server 2008 on a current production box that, then you'll need to plan ahead for the reboot and perhaps do it a few days before you install SQL Server 2008 so you've got it out of the way when the time comes.

Ok, now that we've taken care of the preliminaries, let's install SQL Server 2008.

1. The media will autorun and present you with this screen.

Notice how much info Microsoft gives you right away.  Over on the left there are menu choices and the options on the right change as you go through the menus.  You want to click on the Installation menu on the left to be presented with this screen.

2.  You can see there are many options here, but in this case the only one that makes sense is to click the top option for a stand-alone install.  Click that option.

3.  Once you choose the stand-alone install, setup will install the setup support files.  It does this every time you run the installer so don't be surprised if you run it again and again and it installs them every time.  At this point setup will also run some checks to make sure that your system is ready to run through the install process.  If it's not and something fails, you'll see an error similar to the one below.  In my case I have a reboot pending and setup will not continue until I reboot.

If you don't have any problems with the checks, the screen will be all green like this:

I might also add that if you have to reboot, once your server comes back up setup should continue on its own and re-run this check and if all errors have been eliminated, it should present you with the above screen just as if there had never been a problem.

4.  Click OK.  Next you will be presented with the setup support rules page.  This is another set of checks that tells you whether things will complete and work properly once setup completes.  The screen looks like this.

And again, warnings can be ok, but if there are any errors you'll need to resolve them before moving forward.  I'll talk more about the kinds of things that can go wrong with setup in another article.

5.   Now it's time to choose the installation type.  Are you installing a new instance of SQL Server 2008, or adding to an existing instance?

6.   Now enter your product key if you need to.  There are times when it'll be filled in automatically for instance if you're installing an MSDN version.

7.   Next you need to agree to the license terms.  For the sake of completion I'm going to go ahead and say that you should read all of the license terms so you know what you're agreeing to.  However, assuming you agree and actually want to install SQL Server 2008, then check the box and click next.

8.  This is one of those really important parts of the installation:  choosing features to install.  Unfortunately, since I don't know your goal I can't really offer very much guidance here, but I can tell you that you'll need to install Database Engine Services at a minimum if you want to run a SQL Server 2008 database on the server.  Everything else is optional, but it is a good idea to install the documentation and the management tools.  If you're not sure whether you should install a feature or not there are two bits of advice I can offer.  First, as you click on each option, a description comes up in the right pane that tells you what it's all about so that can help you decide.  And second, installing everything won't hurt your server so if you're not sure, then it's cool to go with a full install.  It's still always best to snipe the features you're after though.

You'll notice that some features are grayed out.  This is because I've already got SQL Server 2008 installed on my box, and some features can only be installed once across all instances.  It doesn't do any good to install multiple copies of the documentation, for example.

9.   This next screen allows you to define whether you want to install a default or a named instance.  You can of course only install one default instance, and all others must be named.  As you can see here, I'm installing a named instance because I've already got a default instance on my box.

10.   This screen outlines the disk space requirements for all the options you've chosen.  There's nothing really to do here and I've never seen it fail since nobody puts a database on a server that can't even hold the install.

11.   Now you need to configure your service accounts.  You can select the same account for all services or separate them into different accounts.  And while detailed advice on that is beyond the scope of this article, I can say that either way is usually ok.  The one piece of advice I can give you though is to make it a domain account instead of just a local Windows account.  And there are special permissions that these accounts need so you should make sure they have those rights.  For a detailed discussion on choosing authentication methods, go to:  How to choose a SQL Server authentication method.

12.  This screen takes a little explanation.  It's asking you which security model you want to run.  It defaults to Windows authentication which should be fine for most shops.  The deciding factor is whether you've got non-windows domains, or if you've got regular windows domains that don't trust each other.  This could be a situation where you've got external customers hitting your database and you don't want to give them windows access, but rather access through some sort of portal.  All the same, it's best to use Windows authentication if your users have Windows accounts.  It's more secure and it's easier for the users to connect to the database.  This screen also wants you to define default data directories.  You can change these at any time once SQL Server 2008 is installed, so you can just accept the defaults here if you like and then change it later if you need to.

13.   This screen gets overlooked by a lot of people.  It's really a good idea to check both of these boxes.  There's absolutely no personal or identifying information sent to Microsoft and checking these boxes allows them to get automatic error and usage information so they can improve the product.  And contrary to popular belief, they actually do look at every error report that comes across.  So check both of these.  It costs you nothing and it helps improve the product.

14.  You're going to learn to hate this screen.  Here we have another set of checks that can stop your install and in my experience, most of the stuff that's going to stop you will happen here… after you've already been through most of the screens.  This topic is too detailed to go into right now, but just know that you can expect some showstoppers here if there are going to be any.  The good news is that you mostly get stopped on upgrade so if you're installing a fresh instance you'll probably be ok.  So once you get all greens you can go ahead.

15.   Assuming you've made it this far you should be free to hit the Install button.  There's nothing really notable about this screen; it's just a summary of all the options you've chosen.  If you like you can look it over and to make sure that you didn't do anything stupid, but I'm usually ready to just start installing at this point so I just bull on ahead.

OK, you've just gone through the setup wizard to install SQL Server 2008.  As you can see it's fairly straight-forward but there are a lot of screens to click through.  This is a much bigger topic than I could ever cover in a single article, but starting with a simple wizard-driven install is a good place to get your feet wet.  In later articles I'll go into more detail on many of these aspects and even get into upgrades, and troubleshooting install errors.