Configuring Disk Quotas in Windows 2003

About Disk Quotas

Unfortunately, in Windows NT Disk Quotas didn’t exist, which was much to the disappointment of Windows Administrators. Along came Windows 2000 and with the introduction of Disk Quotas it meant Administrators had the ability to track and control user disk usage. The only problem was that they didn’t really have a sufficient way of managing disk quotas. Scripting, reporting and remote usage methods were somewhat limited and ambiguous. Windows 2003 offers better all round functionality and easier enterprise-wide disk quota manageability.

Disk quotas are used in conjunction with NTFS, Group Policy and Active Directory technology. NTFS is the file system on which disk quotas can be set, Group Policy is what is used to set disk quotas on a specific set of users and computers, and Active Directory is used to gather a list of users to which the disk quota group policy will be set. It is important to note that disk quotas can only be used with NTFS; setting them up on FAT or FAT32 drives is not possible.

Disk quotas are configured on a per volume basis and cannot be set on a file or folder level. Each volume would have its individual settings which do not affect any other volumes. You may have a single disk partitioned into two volumes (drives C and D for example) with each having their own quota settings. Disk quotas can also be configured on a per user basis and different groups of users can have different limits set. Administrators are the only ones to whom a disk quota does not apply; by default there are no limits for an Administrator.

There are numerous reasons you may wish to make use of disk quotas. Based on the requirements of your organization you might choose to configure disk quotas if you have a restricted amount of disk space on a specific server, a limited number of servers, or perhaps the need to monitor user disk space usage without actually enforcing a quota. You might be wondering why you’d want to just monitor user disk space usage. Well, let’s say you have a fileserver set up with multiple users in your organization using it everyday to store temporary files. As time goes by and perhaps people forget to delete the files from the server, the amount of available disk space will continue to decrease. If nothing is done about it then users will be denied the right to add more files on the server (until some old files are removed). By monitoring user disk space usage with Microsoft’s disk quotas, you can be notified of when space is running out and then increase the allocated space on the server accordingly or notify your users that they need to delete their files from the server. Additionally, setting a quota warning level will allow for a system event log to be written for your review.

Setting a Group Policy

The most practical means of configuring disk quotas on a large scale would be through a domain-level group policy. This will configure the settings automatically on any of the volumes you wish to have disk quotas enabled, saving you the need to have to configure each volume independently.

Open the Group Policy Object Editor (gpedit.msc) and navigate to Computer Configuration > Administrative Templates > System > Disk Quotas. On the right hand pane you will see a list of policies that can be applied. Double click the “Default Quota Limit and Warning Level Properties” setting.

Figure 1: The Default Quota Limit and Warning Level Properties Dialog

The default quota limit is the maximum amount of space assigned per default quota, whereas the warning level is the amount of space at which a warning is triggered. Normally 90-95% of the total value is a good limit to set as a warning.

Now configure any other settings you wish to be applied by selecting them from the right hand pane. To have your changes applied immediately you can enable the “Disk Quota Policy Processing” policy and choose “Process Even If The Group Policy Objects Have Not Changed” from Administrative Templates > System > Group Policy.

Figure 2: The Disk Quota Policy Processing Dialog

You may also want to manually force a group policy update using the gpupdate utility. Simply go to Start > Run and type gpupdate followed by the return key. This will refresh both the computer and user policies.

Whatever changes you make in the group policy will be reflected on the Quota properties tab of each volume you wish to configure in your domain. The options will appear grayed out and non-editable.

Configuring Disk Quotas and Disk Quota Entries

Using the Computer Management console, you can configure disk quotas for a local or remote volume from a central location. To open Computer Management, you have three choices; either right click My Computer and select Manage, type compmgmt.msc in the Run bar or select Computer Management from the Administrative Tools folder.

Select which computer you wish to manage from the root node. To select a remote machine right click the “Computer Management” node, select “Connect to another computer…” and choose the computer you wish to manage. Now, navigate to Storage > Disk Management and select the volume you want to configure from the right hand pane and open the properties dialog. Click the Quota tab and enable the options you want to be enforced.

Figure 3: The Disk Quota Properties Dialog

The traffic lights icon at the top indicate the status of the disk quota; red means quotas are disabled, orange signifies a changeover is taking place (while it rebuilds the disk information), and green means disk quotas are enabled. A textual representation of the status is shown on the right of the image.

Check “Deny disk space to users exceeding quota limit” to have Windows restrict users from adding more data to their allocated disk space when the quota limit has been reached. Users will be unable to add more data until some space is freed up.

As you can see from Figure 3 above, the quota limit for new users is greyed out. This is because we have already set it from the group policy, which overrides any customizable settings on the quota tab of a volume. In this case we have limited the user’s disk space to 500MB and set a warning level to 450MB.

You may choose not to limit disk usage and just enable quotas to track disk space usage on a per volume basis by leaving the “Deny disk space to users exceeding quota limit” checkbox unchecked and logging a warning when a user exceeds the warning level defined as part of the quota limit. Whenever a user exceeds this limit a Warning event log will be written to the Application Event Log and shown in the Event Viewer.

Figure 4: A warning event log for disk quotas

As per there is a known issue in the pre service pack version of Windows 2003 in that the Warning event log is incorrectly shown as an Information log in Event Viewer. In the Quota Entries application however, it is correctly displayed as a Warning.

When you press the Apply button on the Disk Quota Properties Dialog you are notified that the volume will be rescanned to update the statistics and that this operation may take several minutes. Simply press OK to continue and have disk quotas enabled on that volume.

Quota Entries

Click the Quota Entries button on the Disk Quota Properties Dialog to view a list of individual disk quota entries. From this section you can create, delete and manage quota entries for specific users or groups. If a user requires more space than others then you can set this from here.

Go to Quota > New Quota Entry and the Active Directory User Picker will appear. Choose a user from Active Directory and press OK. You will be given the option to limit disk space and set a warning level or not limit disk usage at all.

Figure 5: Adding a new quota entry

Once you have chosen your preferred settings, press OK and the user will be added to the list. You can monitor a user’s disk usage by looking at the properties of each of the columns. ‘Status’ indicates whether the user is within their limit, if a warning has been logged or if the limit has been exceeded; the icon will change accordingly.

Figure 6: Viewing a list of Quota Entries


This article has given you an overview of Disk Quotas in Windows 2003. We’ve looked at why they would be used and how to configure them.

Some Administrators will find they won’t need to utilize Disk Quotas, but for those who do I have no doubt that you will find them very useful indeed.


Windows Server 2012 DHCP (Part 2)

The DHCP Database

Guarding and maintaining the DHCP database is important for system administrators not only to provide consistent performance, but also to minimize unscheduled downtime due to unexpected server or network snags.

The DHCP database is a dynamic database that stores the DHCP configuration information and the lease data for clients that have leased an IP address from the DHCP server; this includes DHCP options, scope configuration, address leases, exclusion, and reservations. By default, the following DHCP database files are stored in the %systemroot%\System32\Dhcp folder.

Dhcp.mdb – This is the DHCP server database file.

Dhcp.tmp – A temporary file that the DHCP database uses as a swap file during database index maintenance operations.

J50.log and J50#####.log – These are logs of all database transactions. These logs may be used by the DHCP server for data recovery.

J50.chk – A checkpoint file that is updated every time data is written to the DHCP.mdb database file. This checkpoint file can be used during recovery to indicate where the recovery or replaying of data should begin.

Backup and Restore

By default, the DHCP database and associated registry entries are backed up automatically at 60-minute intervals. There is no GUI to change the backup interval; however if you want to change the default settings, you can do so in the following registry key:


You can also back up a DHCP database manually at any time. There is no need to stop the DHCP service to perform a backup of the database. The default path for the DHCP backup is systemroot\System32\Dhcp\Backup. It is possible to modify this path in the server properties to point to another hard drive. Backing up the DHCP database over the network is not possible.

You can use the “restore” function in the DHCP server console to restore the database. When performing a restore, after you select the location, the DHCP service stops and the database is restored. You must be a member of the administrators group or the DHCP administrators group to perform a DHCP database restore.

Reconciling scopes helps to resolve inconsistencies on the DHCP database. The DHCP Server service stores detailed IP address lease information in the DHCP database and summary IP address lease information in the Windows Server registry. When you reconcile the DHCP scopes, the detail and summary entries are compared to verify inconsistencies. During this process, the DHCP service may restore those inconsistent IP addresses to the original clients, or it may set aside those IP addresses in the form of temporary reservations with duration equal to the lease time assigned to the scope.

Using DHCP Relay Agents to provide DHCP service across multiple subnets.

DHCPv4 uses IP broadcasts and DHCPv6 uses multicasts; in both cases, DHCP servers are limited to communication within their IP subnet. If your organization has a large number of subnets, you have to either deploy a DHCP server on each subnet or provide DHCP service across multiple subnets by configuring DHCP relay.

Using DHCP relay means that you configure a DHCP relay agent on each subnet where a DHCP server is not present. A DHCP relay agent is a computer or router that listens for DHCPv4 broadcasts from DHCPv4 or DHCPv6 multicast from DHCPv6 clients and then relays them to DHCP servers in different subnets. DHCPv4 and DHCPv6 need separate DHCP relay configurations. In either case however, you cannot deploy the DHCP relay agent component on a Windows Server that is running the DHCP service; the network address translation (NAT) routing protocol component with automatic addressing enabled, or Internet connection sharing (ICS).

DHCP Service Availability

Even though you may be able to service thousands of clients from a single DHCP server, it is a best practice to implement at least two DHCP servers to improve reliability and fault tolerance with the additional benefit in some cases of configuring load balancing to distribute the workload across multiple DHCP servers.

One possible approach is to configure the DHCP service using the Windows Server 2012 cluster feature or a third-party clustering solution. If one DHCP server fails, the DHCP service can fail over to another DHCP server in the cluster. In this implementation, the DHCP servers have access to a storage area network (SAN) where the DHCP database and related files are stored.

To improve availability and load balancing, there are two other Windows Server 2012 DHCP native solutions that are less complicated than deploying Windows Server clusters; they are split scopes and DHCP Failover.

DHCP Split Scopes

Split scope allows you to improve the load balancing and fault tolerance of the DHCP service by configuring two DHCP servers that serve the same subnet without IP address overlapping. This feature is only available for IPv4 and cannot be configured on IPv6 scopes.

Using a wizard-based configuration, you use two stand-alone DHCP servers to make a certain percentage of a scope’s IP addresses available on one DHCP server while the remaining IP addresses are assigned to the second DHCP server. For this to work, each DHCP server is configured with the same scope range but with different exclusions within that range. The exclusions are necessary because the DHCP servers do not share their lease database information. Each server must be configured to assign only a subset of the available IP address from a given scope.

Let’s say that you have a scope of /24 and you want to configure a split scope using two DHCP servers: DHCP1 and DHCP2. You want to assign 70% of the IP addresses in the subnet to DHCP1 and the other 30% to DHCP2.

The DHCP scope may be configured as follows:

DHCP1 Scope configuration:

Range: to
Exclusion: to

DHCP2 Scope configuration:

Range: to
Exclusion: to

As part of the split-scope implementation, you need to specify the second DHCP server involved in the process. Running the Split-scope Configuration wizard on DHCP1 allows you to allocate the IP address pool in the right proportion; the wizard automatically creates the scope and the corresponding exclusions on DHCP2. You still need to activate the scope on DHCP2 before its IP addresses become available to DHCP clients in the network. The figure below show the DHCP split-scope configuration wizard being run from DHCP1.

Figure 1

It is possible to configure a time delay on the DHCP2 server (see figure below). The delay in DHCP Offer allows DHCP2 to wait before responding to DHCP DISCOVER requests from DHCP clients, permitting the DHCP1 server to respond to and accept the DHCPOFFER first. In the event that DHCP1 becomes unavailable, DHCP2 can continue distributing addresses until DHCP1 is available to service clients again.

Figure 2

In our example, DHCP1 manages 70% of the IP addresses in the /24 subnet. This may be a problem if DHCP1 fails and stays out of service for a prolonged period of time, because DHCP2 is responsible only for 30% of the IP addresses within the scope and it could run out of assignable IP addresses quickly.

Wouldn’t it be great if DHCP2 could also manage the other 70% of the address space? How about if both DHCP1 and DHCP2 could manage 100% of the IP address range within the scope in coordination with each other? This is now possible by configuring DHCP failover on Windows Server 2012.

DHCP Failover

DHCP failover allows two Windows Server 2012 DHCP servers to share a common pool of IP addresses in which both servers can have access to 100% of the IP address range in a given scope and either one of them may assign IP addresses to network clients. As the lease information is replicated between the servers, there is no risk of duplicate IP address distribution. Because both DHCP servers are enabled to provide IP addresses and option configuration to the same subnet or scope, the availability and redundancy of the DHCP service is greatly improved.

There are some caveats worth mentioning before you get too excited about DHCP failover and try to implement it in your network. Windows Server 2012 permits only two DHCP servers for failover; this feature applies to IPv4 scopes and subnets and there is no way to configure it on IPv6 scopes. A single DHCP server can have multiple failover relationships with other DHCP servers, but each configuration must be assigned a unique name for the partnerships to work. DHCP failover is time-sensitive so time synchronization is critically important; a time difference between the partners greater than one minute will result in a critical error and the failover process will stop.

DHCP failover can be configured in two different modes: load sharing or hot standby.

In Load Sharing mode (default) both DHCP servers provide IP settings to clients concurrently. By configuring the load distribution ratio you determine your priorities on how the servers respond to IP configuration requests.

In Hot Standby mode you specify a primary DHCP server that actively dispenses IP settings for the scope or subnet and a secondary DHCP server that will only distribute IP settings if the primary server becomes unavailable. You must configure a percentage of the IP address range to be assigned to the standby server. These addresses are delivered during the maximum client lead time (MCLT) interval if the primary server is down. The secondary server takes control of the entire IP range after the MCLT interval expires.

It is important to remind you that whether you are configuring load sharing or hot standby mode, the configured scope is still shared between the two servers. In either case, if one server fails, the other DHCP server will be able to manage the whole pool of IP addresses because the lease information has been replicated all along.

Here are the steps to configure DHCP failover:

  1. In the DHCP console, right-click the IPv4 node, and then click Configure Failover.

Figure 3

  1. In the Configure Failover Wizard, click Next. Any scope that you are configuring for failover must not exist on the partner DHCP server.

Figure 4

  1. On the Specify a partner server to use for failover page, in the Partner Server box, enter the other DHCP server host name or IP Address.

Figure 5

  1. On the Create a new failover relationship page, in the Relationship Name box, enter a unique name and review and/or configure these settings before clicking Next.
  • Maximum Client Lead Time (MCLT): This parameter determines the amount of time a DHCP server should wait when a partner is unavailable, before assuming control of the address range. It also specifies the amount of time for which a DHCP lease may be renewed by either failover peer without previously contacting the other.
  • Mode: Load balance or standby. Load balance gives the option to assign the load balance percentage for each server. Hot standby allows you to set the role of the partner as active or standby and to allocate a percentage of addresses to the standby server.
  • State switchover interval: This option specifies the time interval before a DHCP server is automatically transitioned to a “partner down” state when network communication is interrupted and the DHCP partner is no longer available. By default you must manually switch the status of a DHCP Server to a “partner down” state using the DHCP Management console or PowerShell.
  • Enable Message Authentication: Use to enable or disable authentication of failover replication traffic between servers.
  • Shared Secret: Enter a password to authenticate the failover connection between servers.

Figure 6

  1. Click Finish, and then click Close.

Figure 7

  1. After the wizard runs on DHCP1, we can verify that the failover scope has been created and activated on the DHCP2 server. (See figure below.)

Figure 8

Here we have used the DHCP management console to configure DHCP failover; it is possible to complete the same configuration using Windows PowerShell.

In this article we focused on the Windows Server 2012 DHCP service performance and accessibility issues. We reviewed the DHCP database maintenance, using DHCP relay agents, and the configuration alternatives to improve availability, load balancing and fault tolerance.

Windows Server 2012 DHCP (Part 1)


Dynamic host configuration protocol (DHCP) is one of the most commonly implemented network services in today’s network environments. In this article I will review the deployment and configuration of the DHCP server role in Windows Server 2012. We will revise the DHCP leasing process, DHCP options, DHCPv4 and DHCPv6 scopes, and auto configuration.

The Case for DHCP

DHCP is primarily used to automatically distribute critical IP configuration settings to network clients, eliminating the tedious and burdensome task of manually configuring hosts on TCP/IP-based networks. It also provides configuration information and interacts with other networking services such as domain name system (DNS), windows deployment services (Windows DS) and network access protection (NAP).

Without DHCP service, you have to individually configure each network client with the correct internet protocol settings, including the IP address, the network’s subnet mask, the default gateway, and the DNS server address. These settings are necessary for the network clients to communicate within and outside their network locations. You have to repeat this manual configuration process any time you bring a new device to the network or you move one to a different subnet.

Many organizations manage hundreds or thousands of network client devices, including smart phones, tablets, desktop computers, and laptops. The DHCP service helps to ensure that all network clients have correct configuration settings, eliminating fat fingers and other human errors that may occur when we have to enter the information manually. Network configuration changes can be updated on the DHCP server without having to change the information directly on each client computer.

<SCRIPT language=’JavaScript1.1′ SRC=”;click=;abr=!ie;sz=336×280;ord=1435166877?”&gt; <A HREF=”;abr=!ie4;abr=!ie5;sz=336×280;ord=1435166877?”&gt;

DHCP Server Authorization

In an active directory infrastructure, to prevent an incorrectly configured DHCP server or a rogue DHCP server from distributing IP addresses, DHCP servers are not allowed to start servicing clients before they are authorized to operate in the network. DHCP authorization is the process of registering the DHCP Server in the active directory database to service DHCP clients. An enterprise administrator account is necessary to authorize Windows Server 2012 DHCP servers; once it is authorized, the DHCP server can support multiple domains in the same active directory forest.

A standalone (no domain member) Windows Server 2012 DHCP server can detect an authorized DHCP server in a domain. When that happens, the standalone DHCP server does not lease IP addresses and shuts down automatically.

Deploying the DHCP Server Role

These are the steps necessary to add the DHCP server role to a Windows Server 2012 computer:

  1. In Server Manager, click Add roles and features.

Figure 1

  1. In the Add Roles and Features Wizard, click Next.

Figure 2

  1. On the Select installation type page, click Next.

Figure 3

  1. On Select destination server page, click Next.

Figure 4

  1. On the Select server roles page, select the DHCP Server check box.

Figure 5

  1. In the Add Roles and Features Wizard, click Add Features, and then click Next.

Figure 6

  1. On the Select features page, click Next.

Figure 7

  1. On the DHCP Server page, click Next.

Figure 8

  1. On the Confirm installation selections page, click Install.

Figure 9

  1. On the Installation progress page, wait until the Installation succeeds.

Figure 10

Once the installation completes, you can proceed to authorize the DHCP server or start configuring the DHCP scopes.

DHCPv4 Scopes

By configuring DHCP scopes, you make IP addresses available to the DHCP clients. A DHCP scope is a pool or range of IP addresses that are available for lease from the DHCP server. Usually a DHCP scope is limited to the IP addresses in a prearranged IP subnet. DHCP scopes must be activated before their IP addresses become available in the network.

On Windows Server 2012, you configure a DHCP scope along with the following settings:

Name and description. This is used to identify the scope. The name is mandatory, the description is optional.

IP address range. This is the starting pool of IP addresses that are available for lease. This pool usually lists the entire range of addresses for a defined IP subnet.

Subnet mask. This property provides space to configure the bit length and the decimal notation for the subnet mask.

Both fields are automatically filled when you enter the IP address range. You may need to change those values when using non default class A, B, or C networks. The subnet mask is used to separate the network ID from the host ID component in the IP address; this allows TCP/IP hosts to determine their location in the network.

Exclusions. Here you list single addresses or range of addresses that belong to the IP address pool, but that will not be offered for lease usually because they have been manually assigned to servers in the network. For example, if the DHCP server is deployed to the same subnet, it will need at least one IP address from the pool. That IP address should be excluded from the scope.

Subnet Delay. This is the amount of time in milliseconds that the DHCP server waits before sending a DHCPOFFER. The default value is 0; when having two DHCP servers servicing the same IP subnet, you may change the default settings on your lower-priority DHCP server by increasing the subnet delay value.

Lease duration. This is the amount of time for which clients are allowed to use the IP addresses without renewal. It is recommended to use shorter durations for scopes with limited IP addresses or a significant number of mobile clients, and longer durations for more static networks.

DHCP Reservations:

A DHCP reservation is a given IP address from within a scope that is set aside for lease to a specific DHCP client. DHCP reservation ensures that the IP addresses that you reserve from a configured scope are not leased to any other device in the network. A DHCP reservation also ensures that devices with reservations are certain to have their IP address even if a scope runs out of available IP addresses. The device’s network interface media access control (MAC) address or physical address is necessary to configure a reservation. If the client is already leasing an IP address from a Windows Server 2012 DHCP server, its MAC address will be available from the DHCP management console.

DHCP Options:

DHCP options are configuration settings that are applied to the DHCP clients when they lease or renew their IP addresses from a DHCP server. An option code identifies the DHCP options; many DHCP options are available, among the most common ones are:

  • * Option 003 – Router (the default gateway for the subnet)
  • * Option 006 – Domain Name System (DNS) servers
  • * Option 015 – DNS suffix

On a Windows Server 2012, you can configure DHCP options at the server, scope, reserved client, and class levels. When troubleshooting the DHCP service, it is critically important that you understand the order in which DHCP applies these options to client computers. DHCP options are applied in the following order:

  1. Server level. A server-level option is assigned to all DHCP clients of the DHCP server. Server options can be superseded by scope, class, and client-assigned options.
  2. Scope level. These settings are applied to clients that obtain a lease within that specific scope. Scope options consistently apply to all computers acquiring a lease from a given scope unless they are superseded by class or reserved client options.
  3. Class level. Client class can be user-defined or vendor-defined. A class-level option is assigned to all clients that identify to the DHCP server as members of a class. Class options can be superseded by reserved client level options.
  4. Reserved client level. This is a reservation-level option that is assigned to one DHCP client. If DHCP option settings are configured at each level and they conflict, then the option that is applied last overrides the previously applied setting. Because the reserved client options are the last one to apply, they will override all the previous levels in case of conflicting settings.

DHCP Lease Generation Process

Understanding the steps involved in the lease and renewal of IP addresses helps you troubleshoot problems when clients cannot obtain their configuration from a DHCP server. There are four steps in the DHCP lease process:

  1. DHCPDISCOVER. The DHCP client broadcasts a DHCPDISCOVER packet in the subnet. All computers in the subnet receive this packet; however, only the DHCP server responds. If there is no DHCP server in the subnet, then a computer or router configured as DHCP Relay agent forwards the message to a DHCP server located in another subnet
  2. DHCPOFFER. All DHCP servers that receive the client DHCPDiscover packet reply with a DHCPOffer packet. This packet contains IP configuration settings including an available IP address and subnet mask.
  3. DHCPREQUEST. The client might receive DHCPOFFER packets from more than one DHCP server; if that is the case, the DHCP client typically selects the DHCP server that responded first to its DHCPDISCOVER packet. The client then broadcasts a DHCPREQUEST identifying the DHCP server from which is willing to lease the IP settings. This broadcast reaches all other the DHCP servers so they know which server’s DHCPOFFER the client has accepted.
  4. DHCPACK. The selected DHCP server stores the IP address client information in the DHCP database and sends back a DHCPACK message and any optional configuration parameters. It is possible for the DHCP server to send a DHCPNAK message; this may happen if the IP address is invalid or it is being used by another computer. In this case the client begins the lease process again.

DHCP clients try to renew their leases after every reboot or startup. This is a great feature, especially for mobile devices since users may move their laptops or tables to different locations or subnets and those devices can automatically obtain the right IP configuration to operate in the new environment. The lease period is reset after each renewal. You can force a renewal by executing the following command: ipconfig /renew. If a device stays on, it will attempt to renew its lease when 50% of its lease time has elapsed. This is a transparent background process in which the DHCP client broadcasts a DHCPREQUEST message. If the DHCP server that leased the IP addresses is available, it will send a DHCPACK message back to the client. If some options have changed since the original lease, the DHCP server includes the new values with the DHCPACk message.

If the DHCP client cannot talk with the DHCP server, then the client waits until 87.5 percent of the lease time passes and then tries to renew again. If 100 percent of the lease time has expired and the renewal is unsuccessful, the client goes into autoconfiguration mode.

DHCPv4 Autoconfiguration

If a DHCP server is not available and the previous lease has expired, the client computer executes an automatic private IP addressing (APIPA) process to assign itself a valid IPv4 address from the subnet with a mask of Before it starts using the new IPv4 address, the client performs an address resolution protocol (ARP) test to ensure that the selected IP address is not being used by any other client in that network. After it configures itself with its new APIPA address, the client keeps sending broadcasts every five minutes to the network, trying to contact a DHCP server. Whenever a DHCP server responds, the client negotiates a new lease, and configures the NIC with the new IPv4 address obtained from the DHCP server.

DHCPv6 Scopes

On Windows Server 2012, DHCPv6 scopes are created and configured separately from IPv4 scopes. Let’s review the step-by-step configuration of a DHCPv6 scope.

  1. On the DHCP Server console, right click IPv6 and select New Scope.

Figure 11

  1. On the Welcome to the New Scope Wizard, click Next

Figure 12

  1. On the Scope Name, enter Name and Description information.

Figure 13

  1. On the Scope Prefix, enter the corresponding prefix for your IPv6 network. If you have multiple DHCPv6 servers, the preference value can be modified to indicate your priority among the servers. The lower this value, the higher      the priority.

Figure 14

  1. On the Add Exclusions, enter any IPv6 address that belongs to that scope but has been manually assigned to other devices in the network. This includes the IPv6 address that is manually configured on the DHCPv6 server itself. Additional exclusion can be added after the initial DHCPv6 scope has been configured.

Figure 15

  1. On the Scope Lease, configure two settings:
  2. Preferred Life Time is the length of time that a valid IPv6 address is preferred. When this time expires, the address becomes deprecated but it is still valid.
  1. Valid Life Time is the length of time that an IPv6 is in the valid state. The address becomes invalid after the valid life time expires. The valid life rime must be equal or greater than the preferred life time.

Figure 16

  1. On the Completing the New Scope Wizard, click Finish to activate the scope.

Figure 17

As on IPv4 scopes, you can configure exclusions, reservations, and DHCP options on IPv6 scopes. However, DHCPv6 clients do not use their MAC addresses when contacting a DHCP server. Instead a device unique identifier (DUID) is used by clients to get an IP address from a DHCPv6 server.

DHCPv6 Autoconfiguration

IPv6 supports both stateful address configuration and stateless address configuration. Stateful address configuration happens when a DHCPv6 server assigns the IPv6 address to the DHCPv6 client in conjunction with additional DHCP configuration options.

Stateless address configuration is an autoconfiguration process by which IPv6 clients assign themselves IPv6 address without ever talking to a DHCPv6 server. It is possible to use a combination of both. For example, you may configure your DHCPv6 client in stateless mode so that they don’t need a DHCPv6 server to obtain an IP address, but you may assign the DNS server address to the same clients using a DHCPv6 server.

Even though routers play an important role in the aotuconfiguration process of DHCPv6 clients, even without a router present, hosts in the same subnet can automatically configure themselves with IPv6 addresses based on the link-local prefix of FE80::/64; this allows the clients to communicate in the local subnet without manual configuration. Before using an auto-selected link-local unicast IPv6 address, a duplicate address detection process is performed to ensure that the select IP address is not being used by another host in the subnet. If the duplicate address detection is successful, the link-local address is initialized for the interface.

In this article we concentrated on the deployment of the DHCP server role on Windows Server 2012 and how the DHCP server scopes and autoconfiguration play an important role for IPv4 and IPv6 clients in the network. In our next article we will focus on the DHCP service availability and some of the new features on Windows Server 2012.

Install an Additional Domain Controller from IFM (Install From Media) in Windows Server 2012

We can use the Install from media (IFM) option to install an Additional Domain Controller in an existing domain is the best option such as a branch office scenario where network is slow, unreliable and costly. IFM will minimize replication traffic during the installation because it uses restored backup files to populate the AD DS database. This will significantly reduce the amount of traffic copied over the WAN link. For this Installation process, we have to follow these steps:

  • On the Primary Domain Controller (KTM-DC01-2K12), Create Installation media using Ntdsutil.exe.
  • Add the AD DS role to the member server
  • Select Install from Media option to configure a member server as a new domain controller.

Step 1: To Create Installation Media Using Ntdsutil, follow these steps:

1. Log on to KTM-DC01-2K12, as msserverpro\administrator, then open the Command Prompt, type Activate instance ntds and press Enter.

2. At the ntdsutil prompt, type ifm and then press Enter.

3. At the ifm prompt, type create sysvol full e:\ifm and then press Enter.
Note: Verify folder named IFM on this drive.

4. Type, quit, quit.

5. Then, copy the entire contents from the IFM folder to removable drive because we are going to install Additional Domain Controller at a remote branch office where network bandwidth is limited.

Steps 2: Add the AD DS role to the member server (POK-DC01-2K12):

 1. Open Server Manager, in the toolbar, click Manage, and then click Add Roles and Features.

2. On the Before you begin page, click Next.

3.  On the Select installation type page, ensure that Role-based or feature-based installation is selected and then click Next.

4. On Select destination server page, verify that is highlighted, and then click Next.


5. On Select server roles page, click Active Directory Domain Services, in the Add Roles and Features Wizard windows, click Add Features, and then click Next.

6. In the Select features window, click Next.

7. On Active Directory Domain Services page, click Next.

8. On Confirm installation selections page, select Restart the destination server automatically if required. Click Yes at the message box.

9. Click Install and Installation progress start….

10.  After the Installation is succeeded, click Close.


Step 3: Create Additional Domain Controller Using IFM Data:

1. Log on to server POK-DC01-2K12 with the Domain administrator account.
Note:  Here POK-DC01-2K12 is member server in the domain.

2. Copy the entire contents from the IFM folder on removable drive to the c:\IFM folder on POK-DC01-2K12 Server. Verify that all items have been copied.

3. Open Server Manager, In the Server Manager Toolbar, to the left of the Mange button, click the Yellow Alert button. In the Post-development Configuration Window, click Promote this server to a domain controller.

4. On the Development Configuration page, ensure that Add a domain controller to an existing domain is selected, and confirm that is entered as Specify the domain information for this operation Domain and Click Next.

5. On the Domain Controller Options page, ensure that both Domain Name System (DNS) server and Global catalog (GC) are selected. For the DSRM password, enter P@ssw0rd in both boxes, and then click Next.

6. On the DNS Options page, click Next.

7.  On the Additional Options page, select the check box next to Install from media, in the text box, type C:\Ifm and then click verify. When the path has been verified, click Next.

8. On the Paths page, click Next.

9. On the Review Options page, review the selection and then click Next.

10. On Prerequisites Check page, verify All prerequisite checks are passed successfully and then Click Install and wait while AD DS is configured. While this task is running, read the information messages that display on the screen.

11. On Installation page, wait for the server to restart to complete the AD DS installation.

12. Finally, verify that additional domain controller is successfully installed by using IFM.




Finally, our new Additional Domain Controller has been created from IFM. This will minimize replication traffic during the Installation. This is the best option for a branch office scenario where network bandwidth is limited. I hope this helps.

What is the System Reserved Partition?

In recent versions of Windows, a special hidden partition exists, the so called System Reserved Partition, to support BitLocker full-drive encryption, the boot configuration database, and the Windows Recovery Environment (RE).

If you’re like me, then you’ve supported users who have gathered just enough Windows power user skills “to be dangerous.” Some of these individuals happen upon the Disk Management console, see the hidden System Reserved partition on their system, and want to “experiment” with it, believing the partition to be unnecessary.

Of course, those of us with a bit more experience know that under most circumstances, we don’t want to mess with this partition. To that point, though, how would you answer the question “What is the purpose of the System Reserved partition, anyway?”

As it happens, the System Reserved partition is an unlettered system drive that is automatically created by Windows 7, Windows 8, Windows Server 2008, and Windows Server 2012 during a clean installation.

In Windows 7 and Windows Server 2008, the partition is 100MB. In Windows 8 and Windows Server 2012, it is 350MB.

The three crucial functions provided are as follows:

  • Boot Configuration Store
  • BitLocker Drive Encryption
  • Windows RE

In this blog post I will first show you how to view the contents of the System Reserved partition. Next we’ll cover each of the three functions of the partition. Finally, I will teach you how to delete this partition, which is sometimes a necessary troubleshooting step when you reinstall Windows. Let’s get to work!

Viewing the System Reserved Partition

Open up the Disk Management console and you’ll see why the System Reserved partition is invisible by default–Windows doesn’t associate a drive letter with the partition. I show you the interface below:

View Systen Reserved Partition

You can view the System Reserved partition from DISKPART or the Disk Management console.

All you have to do to view the contents of the System Reserved partition is to attach a drive letter to the drive. To do this, right-click the partition and select Change Drive Letters and Paths from the shortcut menu.

Because all of the contents of the System Reserved partition are hidden, you’ll need to open the Folder Options dialog box, enable the Show hidden files, folders, and drives option, and disable the Hide protected operating system files (Recommended) property.

As you can see in the screenshot below, you can view the partition once it has a drive letter designation and you’ve revealed hidden system files.

Contents of System Reserved Partition

Once you’ve done your homework, you can view the contents of the System Reserved partition

Here is a quick breakdown of the partition-specific file system contents.

  • Boot: This folder contains the boot configuration database and supporting files
  • Recovery: This folder contains the Windows RE environment that is invoked during the system repair process
  • bootmgr: This file is responsible for locating the active partition and parsing the Boot Configuration Database to load an operating system
  • BOOTNXT: This file’s purpose is largely unknown to…well, just about everybody. I believe that the file has to do with CPU Never eXecute (NX) technology. Let me know in the comments if you read or hear anything different.
  • BOOTSECT.BAK: This file is a backup of the computer’s boot sector, which is responsible for locating bootmgr and completing an OS load

The Boot Configuration Data Store

The Boot Configuration Data (BCD) store was introduced in Windows Vista (blech) and fundamentally changed how Windows computers start up. The BCD is physically a binary file in much the same format as the binary Registry hives. Therefore, we need a special tool to view and manipulate the BCD just like we need a Registry editor to modify the Windows Registry.

To that end, we can use the built-in BCDEdit command-line tool, or a third-party utility like the wonderful EasyBCD from NeoSmart Technologies. I show you this interface in Figure 3.


EasyBCD gives you complete control over the BCD

The bottom line, friends, is that the BCD and its associated files represent how the system detects how many (and which) operating systems are present on fixed disks, where they are, and how they load during each system startup.

BitLocker Drive Encryption

When you consider the purpose of BitLocker Drive Encryption–that is to say, to encrypt your computer’s system volume–the necessity of the System Reserved partition becomes clear immediately.

In short, the BitLocker pre-startup authentication and system integrity verification occur on the System Reserved partition. In Microsoft’s literature, they confusingly refer to the System Reserved partition as the system drive.

Windows RE

Windows Recovery Environment (RE) is a graphical troubleshooting environment that is based upon the Windows Preinstallation Environment (Win PE) that Microsoft uses so heavily with their enterprise deployment tools.

We can access the Windows RE either by pressing F8 during system startup (the timeout value is absurdly low so you might need to perform a system hack to configure a more appropriate value), or by accessing the new Advanced Startup options in Windows 8.

By booting into Windows RE, we have started the system from a non-system disk and are therefore free to perform troubleshooting tasks on the system partition without hazard of file locking and/or user logon issues. In the next screenshot I show you most of the Windows RE interface, where you can see what diagnostic or troubleshooting tasks are possible.

Windows RE interface in Windows 8

Windows RE interface in Windows 8

Of course, we can access the Windows RE by booting a computer from the Windows 8 or Windows Server 2012 media. However, the presence of the RE binaries on the System Reserved partition makes it much more convenient for us to get into RE at any time.

Deleting the System Reserved Partition

In my humble opinion, you should leave the System Reserved partition alone. Besides the obvious stuff (this partition contains the boot files, BitLocker keys, recovery environment, etc.), there is the truth of the matter that the partition is incredibly small–you do not need to recover 350MB of space in all likelihood.

AD Backup & health

The procedure to backup AD or DCs has always been (and as for now will always be) to use a VALID system state of a DC. However, times are changing and all kinds of new technologies and ideas are being used. Although I’m DO NOT promote the use of unsupported backup/restore mechanisms I’m going to mention a procedure here that allows you to use one of the unsupported methods. The main reason for this is that the information is publicaly available from Microsoft (Running Domain Controllers in Virtual Server 2005 – but it is INCOMPLETE and will people will hurt themselves if done incorrectly!


  • You are responsible on your own when using this procedure
  • This posting is provided “AS IS” with no warranties and confers no rights!
  • Always test before implementing/using tools/procedures!


BEST and SUPPORTED way for backup/restore of AD/DCs

  • Supported backup/restore mechanisms/tools
  • Using (at least) system state backups

More information:


FAST and UNSUPPORTED ways for backup/restore of AD/DCs

  • Disk images (cloning)
  • Virtual machine images
  • Breaking RAID 1 (mirroring) configurations


Dangers of NOT using supported AD aware backup/restore mechanisms

  • USN rollbacks in AD and in the SYSVOL
  • Inconsistent data in AD and in the SYSVOL
  • Effects:
    • Other DCs know more about a certain DC then the DC itself

Risk mitigation

  • Use ONLY SUPPORTED backup/restore mechanisms!!!
  • Follow instructions in “Running Domain Controllers in Virtual Server 2005”
  • Implement hotfixes: MS-KBQ885875 (W2K) & MS-KBQ875495 (W2K3) (also included in W2K3 SP1)


So let’s take a look at WHAT are USN rollbacks (in AD).

The following example environment where nothing is wrong.



Now lets have a look at the up-to-dateness vector of ALL DCs in the forest on each DC in the forest…


For each DC with its own color the dotted lines should ALWAYS have the same value or lower than the normal line!!! (everything is OK voor ROOTDC001, ROOTDC002 and CHLDDC001)


The following example environment where something IS wrong because a non- AD aware restore solution has been used



Now lets have a look at the up-to-dateness vector of ALL DCs in the forest on each DC in the forest…


For each DC with its own color the dotted lines should ALWAYS have the same value or lower than the normal line!!!. As you can see the ROOTDC001 and CHLDDC001 know more about ROOTDC002 than ROOTDC002 itself and THAT is wrong!


How to detect and recover from a USN rollback in Windows 2000 Server

How to detect and recover from a USN rollback in Windows Server 2003


So what do MS-KBQ885875/MS-KBQ875495 really do?

  • Detect USN rollbacks in AD, NOT in the SYSVOL
  • USN Rollback detection NOT guaranteed for 100%!!!
  • Pauses the NETLOGON service WHEN USN rollback in AD is detected!
  • Disables inbound and outbound AD replication (event ID 1113/1115), NOT SYSVOL replication,  WHEN USN rollback in AD is detected!
  • Logs event IDs 2095 and 2103 in the directory services event log
  • BOTH HOTFIXES also provide:
    • Supported recovery option that mimics a system state restore


That recovery option has the following requirements!

  • Hotfixes installed/implemented PRIOR to the failure
  • Use ONLY images WITHIN the “tombstone lifetime” timeframe
  • Use ONLY images that have NEVER been booted after creation (this is VERY IMPORTANT. If it has been booted into normal DC mode, it is useless and you need to start over!!!)
  • Make sure the SAME DC is NOT running elsewhere
  • Follow requirements and instructions mentioned in:
    • MS-KBQ885875 & MS-KBQ875495
    • “Running Domain Controllers in Virtual Server 2005”

Procedure for using the recovery option:

  • “Restore” the image
  • !!! Boot into DSRM !!! (not connected to the network)
  • Note the value of “DSA Previous Restore Count”
    (HKLMSystemCurrentControlSetServicesNTDSParameters) (Not visible? –> Assume value of 0)
  • Add the entry “Database restored from backup” (DWORD) with a value of 1
    (HKLMSystemCurrentControlSetServicesNTDSParameters) (This triggers the actions needed for AD right after a system state restore!)
  • Stop the “File Replication Service (NTFRS)” and assign the value “D4” (for auth. or primary restore) or “D2” (for an non-auth. restore) to the entry “BurFlags” in (HKLMCurrentControlSetServicesNtFrsParametersBackup/RestoreProcess at Startup)
    (This triggers the actions needed for the SYSVOL right after a system state restore!) (and other replicated DFS namespaces!)
    (also see: Using the BurFlags registry key to reinitialize File Replication Service replica sets –
  • Boot into normal DC mode (not connected to the network)
  • Check the value of “DSA Previous Restore Count”
    (HKLMSystemCurrentControlSetServicesNTDSParameters) (New value = old value + 1)
  • In the DS event log check for event ID 1109
  • In the FRS event log check for event ID 13565 & 13520 if a non-auth. restore was performed for the SYSVOL
  • In the FRS event log check for event ID 13566 if an auth. restore was performed for the SYSVOL
  • Connect to the network again
  • Check the health of the DC (AD & SYSVOL)
    • DCDIAG /D /C /V
  • DONE!


The boot process starts when you turn on your computer and ends when you log on to Windows Server 2003. There can be various reasons for startup failures. Some can be easily corrected, while others might require you to reinstall Windows Server 2003.

This article will help you understand and troubleshoot most of the errors commonly occurring during the Windows Server 2003 boot process.

While diagnosing a server error, it is important to first determine at which stage the error occurred. A server error can occur when the server is booting, during its running time or even when it is shutting down.

The Boot Process

The boot process will slightly differ depending on whether your server is using an x86-based processor or an Itanium-based processor. This article exclusively deals with x86-based boot Process

If you are running Windows Server 2003 on an x86-based platform, the boot process consists of six major stages:

  1. The pre-boot sequence
  2. The boot sequence
  3. Kernel load sequence
  4. Kernel initialization sequence
  5. Logon sequence
  6. Plug and Play detection

Many files are used during these stages of the boot process. The following sections describe the steps in each boot process stage, the files used, and the errors that might occur.

Stage 1: Pre-Boot Sequence

A normal boot process begins with the pre-boot sequence, in which your computer starts up and prepares to boot the operating system.

The computer will search for a boot device based on the boot order that was configured in the computer’s BIOS settings.

Steps in the Pre-Boot Sequence

The preboot sequence is not truly a part of windows booting process.

The pre-boot sequence consists of the following steps:

  1. When the computer is powered on, it runs a power-on self-test (POST) routine. The POST detects the processor you are using, how much memory is present, the hardware is recognized and what BIOS (Basic Input/Output System) your computer is using.
  2. The BIOS points to the boot device and the Master Boot Record (MBR) is loaded. It is also sometimes called the master boot sector or even just the boot sector.The MBR is located on the first sector of the hard disk. It contains the partition table and master boot code, which is executable code used to locate the active partition.
  3. The MBR points to the Active partition. The active partition is used to specify the partition that should be used to boot the operating system. This is normally the C: drive. Once the MBR locates the active partition, the boot sector is loaded into memory and executed.
  4. The Ntldr file is copied into memory and executed. The boot sector points to the Ntldr file, and this file executes. The Ntldr file is used to initialize and start the Windows Server 2003 boot process.

Possible Errors & Solutions

If you see errors during the pre-boot sequence, they are probably not related to Windows Server 2003, since the operating system has not yet been loaded. The following table lists some common causes for errors and solutions .



Corrupt MBR There are many viruses that affect MBR and corrupt it. You can protect your system from this type of error by using a virus-scanning software. Most of the commonly used virus-scanning programs can correct an infected MBR.
Improperly configured hardware If the POST cannot recognize your hard drive, the pre-boot stage will fail. This error can occur even if the device was working properly and you haven’t changed your configuration. Recheck your device configuration, driver settings. Also check for any hardware malfunction and failure.
No partition is marked as active This can happen if you used the Fdisk utility and did not create a partition from all of the free space. If you created your partitions as a part of the Windows Server 2003 installation and have dynamic disks, marking an active partition is done for you during installation. If the partition is FAT16 or FAT32 and on a basic disk, you can boot the computer to DOS or Windows 9x with a boot disk. Then run Fdisk and mark a partition as active.
Corrupt or missing Ntldr file There are chances that, Ntldr file may be corrupted or deleted by virus attack. . You can restore this file through Automated System Recovery or a Windows Server 2003 boot disk.

Back to the Top

Stage 2: Boot Sequence

When the pre-boot sequence is completed, the boot sequence begins. Ntldr switches the CPU to protected mode, which is used by Windows Server 2003 and starts the appropriate file systems.

The contents of the Boot.ini file are read and the information is used to build the initial boot menu selections. When Windows Server 2003 is selected, gathers the system’s basic hardware configuration data and passes the collected information back to Ntldr. The system also checks to see if more than one hardware profile is detected; if so, the hardware profile selection menu will be displayed as a part of the startup process.

Possible Errors & Solutions

The following table lists some common causes for errors during the boot stage.



Missing or corrupt boot files If Ntldr, Boot.ini, Bootsect.dos,, or Ntoskrnl.exe is corrupt or missing (by a virus or malicious intent), the boot sequence will fail. You will see an error message that indicates which file is missing or corrupt. You can restore these files through Automated System Recovery.
Improperly configured Boot.ini file It can occur when you manually edit Boot.ini or if you have made any changes to your disk configuration. Recheck your configuration.
Unrecognizable or improperly configured hardware If the error that appears is due to, the issue is surely due to hardware problems. Best method to trouble shoot it is to remove all the hardware that is not required to boot the computer. Add each piece one by one and boot your computer. This will help you to identify the culprit.

Important Files

Along with the Ntldr file, which was described in the previous section, the following files are used during the boot sequence:


This is used to build the operating system menu choices that are displayed during the boot process. It is also used to specify the location of the boot partition. This file is located in the root of the system partition. It has the file attributes of System and Hidden.


An optional file that is loaded if you choose to load an operating system other than Windows Server 2003, Windows 2000, or Windows NT. It is used only in dual- boot or multi-boot computers. This file is located in the root of the system partition. It has the file attributes of System and Hidden.

Used to detect any hardware that is installed and add that information about the hardware to the Registry. This file is located in the root of the system partition. It has the file attributes of System, Hidden, and Read-only.


Used to load the Windows Server 2003 operating system. This file is located in WindirSystem32 and has no file attributes.

Steps in the Boot Sequence

The boot sequence consists of the following steps:

  1. Ntldr switches the processor from real mode to protected mode. Then it starts file system drivers which supports your computer’s file system.
  2. Ntldr is responsible for reading Boot.ini file. It displays a “boot menu which lets users to choose the operating system to load.If we choose an operating system other than Windows server 2003 say Windows 2000, or Windows NT, the Bootsect.dos file is used to load the alternate operating system, and the Windows Server 2003 boot process terminates.
  3. file performs a hardware scan/detection and any hardware that is detected is added to registry in the HKEY_LOCAL_MACHINE key. The hardware that will recognize includes communication and parallel ports, the keyboard, the floppy disk drive, the mouse, the SCSI adapter, and the video adapter.
  4. Control is passed to Ntoskrnl.exe to start the kernel load process.

Back to the Top

Stage 3: Kernel Load Sequence

All of the information that is collected by is passed to Ntoskrnl.exe.

The kernel load sequence consists of the following steps:

    1. The Ntoskrnl.exe file is loaded and initialized.
        • Initializes executive subsystems and boot system-start device drivers.

      NOTE: By executive subsystems, I meant Process and Thread Manager, The Virtual Memory Manager, The Input/Output Manager, The Object Manager, Runtime Libraries which all runs in kernel mode.

        • Prepares the system for running native applications.

      NOTE: If you are not familiar with native applications, then it needs explanation. Windows provide two type of API. Well known Windows API (All Windows programs must interact with the Windows API regardless of the language.) and Native API. Native API is used by some windows components like kernel level drivers and system process aka csrss.exe

      • runs Smss.exe.

The function of Ntoskrnl.exe:

  1. The Hardware Abstraction Layer (or HAL) is loaded. The HAL is a kernel mode library (HAL.DLL) that provides a low-level interface with the hardware. Windows components and third-party device drivers communicate with the hardware through the HAL.
  2. The control for the operating system is loaded. The control set is used to control system configuration information such as a list of device drivers that should be loaded.
  3. Low-level device drivers, such as disk drivers are loaded.

Possible Errors & Solutions:

If you have problems loading the Windows Server 2003 kernel, you will most likely need to reinstall the operating system.
Back to the Top

Stage 4: Kernel Initialization Sequence

In the kernel initialization sequence, the HKEY_LOCAL_MACHINEHARDWARE Registry is created, device drivers are initialized, and high-order subsystems and services are loaded.

The kernel initialization sequence consists of the following steps:

1. Once the kernel has been successfully loaded, the Registry key HKEY_LOCAL_MACHINE HARDWARE is created. This Registry key is used to specify the hardware configuration of hardware components when the computer is started.

2. The device drivers that were loaded during the kernel load phase are initialized.

3. Higher-order subsystems and services are loaded.

Note: Higher order subsystem include, POSIX Subsystem, OS/2 subsystem.

Possible Errors & Solutions:

If you have problems during the kernel initialization sequence, you may trying booting to the Last Known Good configuration.
Back to the Top

Stage 5: Logon Sequence

Session Manager Subsystem or smss.exe plays a vital role in logon sequence. Its main function include.

1. It creates environment variables in the operating system.

2. It Starts the kernel and user modes of the Win32 subsystem (win32k.sys and csrss.exe). It then starts other subsystems that are listed in HKLMSystemCurrentControlSetControlSession ManagerSubSystems Registry key.

3. smss.exe starts winlogon.exe, the Windows logon manager.

winlogon.exe is a system service that enables logging on and off of users. It is also responsible for loading user profile.

It invokes GINA( Graphical Identification and Authentication) which displays login prompt. The GINA accepts the user login credentials and passes it back to Winlogon.

Winlogon then Starts Lsass.exe (the Local Security Authority) and passes login credentials to LSA. LSA determine which user account databases is to be used for authentication eg: Local SAM or Active Directory in case you are in a windows domain.

4. smss.exe finally starts the Services subsystem (Services.exe), also known as the Service Control Manager (SCM). It executes and performs a final scan of HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices to see if there are any remaining services that need to be loaded.

Possible Errors & Solutions

  1. If logon errors occurs, they are usually due to an incorrect username or password or to the unavailability of a DNS server or a domain controller to authenticate the request (if the computer is a part of a domain).
  2. Errors can also occur if a service cannot be loaded. If a service fails to load, you will see a message in the System Log of Event Viewer.

Back to the Top

Stage 6: Plug and Play Device Detection Phase

If Windows Server 2003 has detected any new devices during the startup process, they will automatically be assigned system resources.

If the device is Plug and Play and the needed driver can be obtained from the file, they are extracted.

Device detection occurs asynchronously with the initial user logon process when the system is started.

Possible Errors & Solutions

If the needed driver files are not found, the user will be prompted to provide them. If you have already installed the driver, then a simple reboot should detect the driver.

Most of the problem that occur at this stage can be corrected by a reboot.

– See more at:

%d bloggers like this: