Automatic Logon on Windows Server 2003

This article describes how to configure Windows to automate the logon process by storing your password and other pertinent information in the registry database. With this feature, other users can start your computer and use the account that you establish to automatically log on.

IMPORTANT: The autologon feature is convenient; however, this feature may be a security risk. If you set a computer for autologon, anyone who can physically obtain access to the computer can gain access to all of the computer's contents, including any network or networks it is connected to. Additionally, when autologon is turned on, the password is stored in the registry in plain text. The specific registry key that stores this value can be remotely read by the Authenticated Users group. This setting is only recommended for cases it which the computer is physically secured and steps have been taken to make sure that untrusted users cannot remotely access the registry.

Use Registry Editor to turn on automatic logon

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

To use Registry Editor (Regedt32.exe) to turn on automatic logon, follow these steps:

1. Click Start, and then click Run.
2. In the Open box, type Regedt32.exe, and then press ENTER.
3. Locate the following subkey in the registry:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
4. Double-click the DefaultUserName entry, type your user name, and then click OK.
5. Double-click the DefaultPassword entry, type your password, and then click OK.NOTE: If the DefaultPassword value does not exist, it must be added. To add the value, follow these steps:
   
   
   1. On the Edit menu, click New, and then point to String Value.
   2. Type DefaultPassword, and then press ENTER.
   3. Double-click DefaultPassword.
   4. In the Edit String dialog, type your password and then click OK.
   NOTE: If no DefaultPassword string is specified, Windows automatically changes the value of the AutoAdminLogon key from 1 (true) to 0 (false), disabling the AutoAdminLogon feature.
6. On the Edit menu, click New, and then point to String Value.
7. Type AutoAdminLogon, and then press ENTER.
8. Double-click AutoAdminLogon.
9. In the Edit String dialog box, type 1 and then click OK.
10. Quit Registry Editor.
11. Click Start, click Shutdown, and then type a reason in the Comment text box.
12. Click OK to turn off your computer.
13. Restart your computer. You can now log on automatically.

Notes To bypass the AutoAdminLogon process and to log on as a different user, hold down the SHIFT key after you log off or after Windows restarts.

Registry change will not work if the “Logon Banner” is defined on the server either by a Group Policy object (GPO) or by a local policy. When policy is changed to not impact server, the feature works as expected.

An interactive console logon that has a different user on the server changes the DefaultUserName registry entry as the last logged on user indicator. AutoAdminLogon relies on the DefaultUserName entry to match the user and the password. Therefore, AutoAdminLogon may fail. You may configure a shutdown script to set the correct DefaultUserName entry for AutoAdminLogonAs. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

119364 AutoAdminLogon loses DefaultUserName

More about → Automatic Logon on Windows Server 2003

Zero Backup

Some companies have begun to do away with traditional backup that supports a concept called zero backup, where there is no backup was made. Is zero backup is really the way of the future?Over recent years the nature of backup data centers have evolved into something almost unrecognizable. In the not too distant past, the accepted way of doing backups is to put a bunch of cassette tapes and let the magazine run up late at night. Today, this approach is rarely a viable option. Most data centers operate 24 hours a day, which makes the concept obsolete nightly backup.In addition to time constraints, there are many additional factors that will change the way the backup should be done. These factors run the gamut from the recovery time objective for service level agreements. Because of these and other factors that countless organizations have been forced to adopt technologies such as next-generation backup backup backup snap shot or continuous data protection. Still others have adopted a more radical approach - the concept of backup just leave altogether.The concept has come to be known reserves left as zero reserves. The basic idea behind zero backup is that if you have enough redundancy in place then there is no need for a backup.Technically zero backups can still be considered as a backup - albeit very non-traditional. After all, the backup is really nothing more than a copy of your data is stored in a safe place so it can be restored if something ever happens to the primary data source. Backup zero may not involve copying data to tape or other backup media, but the redundancy involved in the underlying architecture ensures that there are multiple copies of the organization's data. Therefore, it could still be considered zero backup as the backup type.So how zero backup work? I first heard the concept about a year ago related to Exchange Server 2010, but the concept has since expanded to include other server products. Even so, I will talk about zero backups of Exchange Server candidate since zero backup for Exchange has been used for a while.It makes zero backup for Exchange Server is probably the structure known as the Database Availability Group. Database availability group failover cluster similar in that they provide the Exchange server box with redundancy and fault tolerance. In fact, even the availability of the database relies on Windows Failover Cluster Services. Unlike other types of cluster failover However, database availability groups Exchange does not rely on shared storage.Lack of shared storage is one key to back up practical zero. In a cluster that relies on shared storage, storage itself (and the data stored in the storage array) can be a single point of failure. In the Database Availability Group, mailbox database replicated between cluster nodes.Those familiar with Exchange Server may be quick to point out that the Exchange 2007 database replication capabilities are also offered through local continuous replication and Replication constantly alert. Database availability groups can be considered as the next generation solution continuous replication.Cluster continuous replication deployment typically consists of either three or two-node cluster nodes and cluster file share witness. Conversely, an Exchange 2010 database availability group can include up to 16 mailbox servers.In most cases, has sixteen replica of the mailbox database would be overkill, but the number of mailbox servers in a database availability group does not necessarily reflect the number of database replicas. The reason for this is simple. Each mailbox server that can accommodate multiple Exchange Server database. Exchange 2010 database availability groups let you host your database locally on each database availability group member, but they also allow you to replicate the database for each member of a database availability group that you select. Replication performed at a database level, not on a per server. That means that you are free to replicate several databases and not others or to replicate different databases to database availability group members are different.So what does all this have to do with zero backup? In the case of Exchange Server, database replication boxes are usually configured in a way that provides the greatest resilience.Of course there is a difference between fault tolerance and backing up your data, so you may be wondering how the database availability group can facilitate things like point in time recovery or offsite storage.Offsite storage is made possible by the fact that the availability datacenter single database can span. For example, if your organization has data centers in Miami and Las Vegas then you can create a single database availability groups and mailbox covers server from both locations. You may have multiple Exchange Servers in Miami which is usually in the service user's Miami office. Database servers can be replicated their mailboxes to Las Vegas datacenter for safe keeping. Similarly, Exchange Server in Las Vegas office may include a mailbox for the user in the Las Vegas office, but they can be replicated mailbox database to Miami. Basically, each server box in the availability of database replicas has the potential to host a database of both Miami and Las Vegas. You are free to mix and match the replica as your needs dictate.Although offsite replica gives you a way to keep a copy offsite data server mailbox, there is still a problem point in time recovery. Suppose for example that the mailbox database full of viruses. Damage to the database will be replicated to all other database replicas. So how can you restore the database to a previous point in time if you do not do backups?Exchange 2010 offers a feature called copy behind. Left is a replica copy of the database set up so that the changes are not immediately committed to the database. For example, you might set a replica of the database with a time lag of the day. Replication others may have a week lag time. If the unthinkable should happen then you can use the replica left to return to the point in time before the database corruption that has ever happened.Throughout this article, I have shown you how the database availability group could conceivably make a traditional backup unnecessary. Even so, we must ask whether this and similar technologies actually do away with the need for traditional backup.Several organizations have been totally committed to using zero backup. The organization has sufficient redundancy in a place that they do not feel as if they even need to make a backup again.Personally, I would be really nervous about the idea of ​​giving up my backup supports backup zero. Despite the availability of databases and similar technology could potentially eliminate the need for a backup, I have worked in IT long enough to know that sometimes the unexpected happens. If disaster ever did result in data loss, I just can not imagine having to explain to my clients that their data is lost because I choose not to back up. For those who work in the corporate world, I would imagine that it would equally not fun trying to explain to your boss why you have no backup.

More about → Zero Backup

Remote Desktop Troubleshooting

Remote Desktop Connection

Since the release of Windows XP, one of my favorite features as always Remote Desktop. In case you are not familiar with Remote Desktop, it is a built-in feature of Windows that allows you to connect to your computer remotely using RDP protocol. For example, if you are at home and you need to access something from your computer at the office, you can use the Remote Desktop session to remotely control your office PC from home. Remote Desktop is built on the same technology, and using the same protocol with Windows Terminal Services.As useful as Remote Desktop is, can sometimes cause problems. While the sessions are usually solid, there are a number of things that can go wrong during the connection and authentication process. In this article, I will discuss some different troubleshooting techniques that you can use when there is an error with Remote Desktop.

The Remote Computer Could not be Found

Probably the most common problem that Remote Desktop Remote Desktop has trouble remote PC. There are several things that can cause this problem. Perhaps the most simple is the misspelling of the name of the remote computer. Therefore, if you are having trouble connecting to the remote computer, just take a second and make sure that you have spelled the name of the remote machine correctly.If the remote computer name spelled correctly, the problem may be DNS related. Remote Desktop uses RDP protocol, which piggybacks on top of TCP / IP. As you probably know, TCP / IP does not use the computer name as a mechanism to identify the system. The only reason that it is possible to specify the name of the computer is that the DNS server resolves computer names to IP addresses.If you find yourself having name resolution problems, there are several different things you can try. One option is to try to use the name of the remote system is the fully qualified domain as opposed to its NetBIOS name. It will not always help you to make the connection, but in certain situations will help.Another option is to specify the IP address of the remote machine rather than by name. In general, use IP addresses tend to be much more problematic than using a host name when connecting. Even the IP address can be a problem, though.The biggest factor that tends to make the link with the IP address problematic is the use of dynamic IP addresses. If you are using Remote Desktop to connect to the server, it may not be a problem, since most servers use static IP addresses. Workstation, on the other hand, almost always using a dynamic IP address. Therefore, the IP address of the workstation you are using today may tomorrow be assigned to different workstations. If the machine is not connected to a dynamic IP address to use, then you will practically have no choice but to set the hostname when connecting rather than setting the machine's IP address.Another factor that can make it difficult to connect to the host machine using the remote desktop firewall. Remote Desktop Protocol is designed to work on TCP port 3389. If you try to connect to a remote machine that sits behind a firewall, the firewall must allow traffic to flow through TCP port 3389. Of course blindly open this port on your firewall can pose a major security risk. You may choose not to turn on port forwarding so that incoming RDP traffic is forwarded to a specific IP address, rather than someone on the outside can try RDP connections to any machine on your network.On many networks, you'll have no choice but to use port forwarding for RDP traffic. Most networks use private IP addresses on their networks, and only the router using a public IP address. The router uses Network Address Translation (NAT) to proxy traffic between hosts on the Internet and private networks. If you are trying to establish RDP connections from all over the internet with a host that sits behind a NAT firewall, then you will have to configure the firewall to forward RDP traffic to the target host.Of course this assumes that you're trying to make a direct connection from outside the network perimeter. If you are connected to a private network using a VPN or dial-up connection, then you will have to worry about reconfiguring the NAT firewall, because your VPN or dial-up connections provide you with a connection to the private network. Remote access server that is used to build a VPN or dial-up connection is almost always sitting behind a firewall, and you must ensure that your firewall allows RDP traffic flowing to a private network.While I'm on the subject of firewalls, I want to point out that Windows XP SP2 and Windows Vista both contain a built-in firewall. If you try to connect to a machine running an operating system, you must make sure that the Windows firewall is configured to allow RDP traffic. 

Authentication Problems

 Building the initial connection is by far the most problematic aspect of the Remote Desktop, but there are other problems that you may encounter. Many users are surprised to see that they can attach to a remote PC and enter their credentials, but was stopped by the following error message:Local policy system does not permit you to logon interactively.Windows displays an error message if the user who is logging do not have the permission required to log in using the Remote Desktop Protocol. You can fix this problem by adding a user account to the Remote Desktop Users group or the local Administrators group. 

Data Encryption

 One of the most complex problems with Remote Desktop involves receiving the following error message:Due to an error in data encryption, this session will end. Please try connecting to the remote computer again.This error message is almost always associated with using outdated remote desktop (or terminal services) clients. When Microsoft released Windows 2000, they created an add-on called Pack Administration Tool. The Administration Tool Pack includes client components that can be used to build a remote session. Although the client is initially appear to be compatible with Windows XP, it is not. Using the Windows 2000 Administration Tools Pack version to establish a Remote Desktop session with Windows XP will usually trigger an error message that I mentioned above.Windows XP comes with the company's own Remote Desktop client that you can use to make a connection with another computer running Windows XP. If you prefer to use the Administration Tools Pack though, then you can always upgrade to version Server, Windows 2003 which you can download at: http://support.microsoft.com/kb/304718
Although Remote Desktop usually works pretty well, sometimes it can be difficult to establish the initial connection. In this article, I have discussed some of the most common causes of problems Remote Desktop and some possible work arounds.

More about → Remote Desktop Troubleshooting

Troubleshooting Logon Failures In Active Directory Environments

 Log in to the computer is a routine part of the day that is easy to not think about the login process. However, things can and sometimes go wrong when users log on to Windows. In this article, I will talk about some of the things that can cause logon failures, and show you how to get around the problem.

Troubleshooting Logon Failures in Active Directory

Before I begin, I just want to quickly mention that in order to provide as much useful information as possible, I would avoid talking about the most obvious cause of the logon failure. This article assumes that before you begin the process of solving a problem, you've checked to make sure that the user enters the correct password, the user's password has not expired, and that there is no basic communication problems between the workstation and the domain controller.

It may seem strange, but true workstation at logon failure may be the cause. If the clock more than five minutes different from the time on your domain controller, then the logon will fail.

In case you are wondering, the reason for this has to do with the Kerberos authentication protocol. At the beginning of the authentication process, the user enters their username and password. Workstation then sends a Kerberos Authentication Server to Server Request Distribution Key. This Kerberos Authentication Server Request contains several different pieces of information, including:• Identify users• The name of the service that the user requested (in this case the ticket Acquiring Services)• An authenticator encrypted with the user's master key. This user's master key to encrypt user passwords obtained by using one-way function. 

When the Key Distribution Server receives the request, looks Active Directory user account. It then calculates the user's master key and uses it to decrypt the authenticator (also known as pre-authentication data).When a workstation user created authenticator, it puts the time stamp in an encrypted file. Once the Key Distribution Server decrypts files, it compares the timestamp to the current time on the clock itself. If the time stamp and the current time is within five minutes of each other, then the Kerberos Authentication Server Request assumed to apply, and the authentication process continues. If the time stamp and the current time is more than five minutes, then Kerberos assumes that the request is a replay of previously captured packet, and therefore rejected the logon request. When this occurs, the following message appears:The system can not log on due to the following error: There is a time difference between the client and the server. Please try again or consult your system administrator.The solution to this problem is simple, just set the clock to match the workstation controller clock domain.
The main cause of the problem is the failure of logon global catalog server. A global catalog server is a domain controller that has been configured to act as a global catalog server. Global catalog server contains a searchable representation of every object in every domain of the entire forest.When the forest was originally created, the first domain controller that you bring it online automatically configured to act as a global catalog server. The problem is that this server can become a single point of failure, because Windows does not automatically designate any other domain controller to act as a global catalog server. If the global catalog server fails, then the only domain administrators will be able to log into Active Directory.Given the importance of a global catalog server, you must work to prevent the failure of a global catalog server. Luckily, you can assign any or all of your domain controllers to act as a global catalog server. Keep in mind though that you only have to configure all of your domain controllers to act as a global catalog server if the forest is made up of a single domain. Have some global catalog server is a good idea even for forests with multiple domains, but figuring out which domain controller to act as a global catalog server is something of an art form.If your global catalog server has failed, and nobody can get in, then the best thing you can do is to work to restore the global catalog server to a functional state. There is a way to allow users to log in even if the global catalog server is down, but there are security risks associated with doing so.If Active Directory is running in native mode, the global catalog server is responsible for checking the user's universal group memberships. If you choose to allow users to log on for the failure, then the universal group membership will not be checked. If you have been assigned to members of the explicit rejection of certain universal, then they will not take effect until the rejection of a global catalog server is brought back online.If you decide that you need to allow users to log on, then you will have to edit the registry on each of your domain controllers. Keep in mind that editing the registry is dangerous, and that making a mistake can destroy Windows. Therefore, I suggest making a full system backup before proceeding.

With that said, open the Registry Editor and navigate through the registry tree to HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa. Now, create a new DWORD value named IgnoreGCFailures, and set the value to 1. You will have to restart the domain controller after making this change.
If you suddenly discover that no user can log into the network, and your domain controllers and global catalog servers seem functional, the DNS server failure may occur. Active Directory is completely dependent on the DNS service.DNS server contains host records for each computer in your network. Computers in your network using host records to resolve computer names to IP addresses. If the DNS server failure occurs, then the host name resolution will fail, ultimately affects the logon process.There are two things you need to know about DNS failure in relation to logon problem solving. First, the logon failure may not happen immediately. The Windows operating system maintains a cache DNS, which includes the results of previous DNS queries. This prevents the workstation cache of DNS servers by flooding name resolution requests for the same thing over and over again.In many cases, the workstation will have cached the IP address of the domain controllers and global catalog servers. However, items in the cache DNS do eventually come to an end and will need to be refreshed. You will most likely begin to see the problem when the logon cache host records start over.Another thing you need to know about the DNS server failure is that often there are many other symptoms besides logon failure. Unless the machine on your network is configured to use a secondary DNS server in case the primary DNS server fails, the entire Active Directory environment will eventually come to a grinding halt. Although there are exceptions, in general, the absence of DNS servers on the network Active Directory basically amounted to a total communication breakdown.
Although I have discussed some of the major causes of failure in the network logon Active Directory, an essential part of the process of solving the problem is to see how widespread the problem is. For example, if only a single host on a large network logon problems, then you may be able to get rid of the DNS or global catalog failure. If DNS or global catalog failure is to blame, then the problem is likely to spread more widely. If the problem is isolated to a single machine, then the problem is most likely related to connectivity, the machine configuration, or the user account.

More about → Troubleshooting Logon Failures In Active Directory Environments

DNS For Client IP Configuration

In Active Directory network there many moving parts that need to be understood to help track down problems that may occur to the domain controllers, servers, and desktops. From the desktop troubleshooting, many things can be traced back to an IP address that is configured for IP DNS properties. If the IP address of the DNS is not correctly, many errors will occur, mostly behind the scenes and will not show you what the real problem is. In order to see what could go wrong, and to understand what is going on behind the scenes, this article will explain all the moving parts to flush common problems. When you finish reading, you will have a better understanding of how your desktop (and even the server) to obtain all the information they need to authenticate and access the network resources.

During boot, the operating system will do what it takes to get the core Windows files and parameters in place. This is done by the boot.ini, NTOSKRNL, and other files. All these files do is make sure that the last operating system and boot configuration put in place. This would include, Registry configuration file, and even down to ensure the correct operating system is selected, if there is some loaded on the computer.Once the operating system is ready, the computer need to configure the network. For most companies the network is configured to use DHCP, which stands for Dynamic Host Configuration Protocol. DHCP is very popular and most of you reading this already know that abbreviation. In order for you to contact the DHCP desktop it does broadcast network to contact the DHCP server. The DHCP server (s) have been listening to the request and will catch the broadcast request and respond when one of them heard the request.Note:Starting back in Windows 2000 if there is no DHCP server responds (meaning there is one in a network that does not respond or does not exist at all for the network), the desktop will automatically configure the IP address for itself. This is the APIPA address, which stands for Automatic Private IP Address. Range APIPA IP address 169.254.0.1 is to 169,254,255,254.When desktop communicate with the DHCP server, it will receive an IP configuration related. Configuring the DHCP server IP provides to its clients include:IP addressSubnet maskDefault GatewayDNS IP addressesWINS IP addressesDNS domain nameIf the desktop does not receive the correct IP settings, such as IP address or subnet mask, the desktop may not even communicate with other computers on the network. If the default gateway is the one given, then the desktop will not be able to communicate outside the subnet, which may not include a DNS server.If the desktop is configured to have the user be a local administrator, the user can also change the IP address manually. This will override the settings received by the DHCP server and in some cases can eliminate all communication with the DHCP server. In the end, the desktop can be restricted from communicating with all other computers on the network. It may also fail to communicate with the DNS server is correct, if not correct DNS server entries for the network and Active Directory domain where the desktop is.Now the desktop has all IP configuration information is important, it is now necessary to find and communicate with a domain controller for Active Directory domain. Instead of the initial communication is broadcast, as it was to communicate with the DHCP server, desktop directly communicate with the DNS server has been configured to locate a domain controller.Desktop makes direct contact with the DNS server and wait to hear back from the DNS server with information about the domain controller. When a DNS server receives a request from the desktop, it should analyze the information it receives.

• The DNS server will evaluate which subnet the active desktop, based on the IP address and subnet mask configured on the desktop

• The DNS server must evaluate which Active Directory site is located in the desktop, when a site is configured in DNS

• The DNS server must evaluate the sequence domain controller responds with, based on the priority domain controllers, sites, and the domain controller is configured to be used for other sites

The results that provide DNS server to the desktop called DCLIST, and is a hierarchical list of DNS domain controller based on criteria that were made during the analysis. The top DCLIST have a domain controller on the desktop site, then no other domain controllers in the site.Server DNS also provides other SRV (the service resource records) to the desktop, which is needed. This will include (for the Kerberos key distribution center) and KDC DFS server (if configured in DNS).If the desktop fails to obtain the SRV record will fail to use anything related to Active Directory, due to the fact that the only way the client can use the Active Directory is to acquire TCP, LDAP, DC, and KDC SRV records obtained from the DNS. This will make Kerberos fails, Group Policy failed, and all other communication to the domain controller through Kerberos and LDAP failed.Now the desktop has an IP address of a domain controller, it can make a direct connection to the first domain controller in the list. This should be a fast connection, a domain controller must be in the desktop site '.If the domain controller is available, it will respond and communicate with desktop and domain controllers. Desktop provides information to the domain controller so that the desktop can be confirmed as a member of a domain.Once the desktop is authentic, the desktop will receive important information designed to receive, such as startup scripts, Group Policy settings, etc. It is communicated from the domain controller via a secure connection, which split off from the domain controller via the NETLOGON share.There is a good chance will eventually authenticate desktop, but will use NTLMv2 or NTLM. Kerberos is only used when the desktop can obtain KDC and SRV records from DNS. Again, if there is no communication with the Kerberos domain controller, all functions of Active Directory failed to desktop.As you can see the DNS configuration for a desktop is very important. If there is an incorrect setting on the desktop, either manually or from a DHCP server, the desktop will not properly communicate with the DNS server or an Active Directory domain controller. With so much riding on the correct DNS configuration, it is important that DNS is configured correctly for all Windows computers are joined to an Active Directory domain. Without proper configuration, the desktop will not use Kerberos, Group Policy will not accept, and will not be able to use Active Directory correctly, due to the fact that no communication was made to the DNS server to accept the Active Directory SRV records placed there to find the source AD power.

More about → DNS For Client IP Configuration