Win 2003 & Active Directory : Slow Startup & Shutdow
As the title says, I'm experiencing some problems with starting up and shutting down my PC, after I've installed Active Directory. It seems impossible to find any other topics about this, but I've heard that lots of others have this problem.
As the title says, I'm experiencing some problems with starting up and shutting down my PC, after I've installed Active Directory.
It seems impossible to find any other topics about this, but I've heard that lots of others have this problem.
Perhaps the biggest disadvantage is that I can't put my PC in standby-mode anymore, which I did everyday before now ...
Does anyone have solutions for this? I'd love to hear them !
Regards,
Niels
It seems impossible to find any other topics about this, but I've heard that lots of others have this problem.
Perhaps the biggest disadvantage is that I can't put my PC in standby-mode anymore, which I did everyday before now ...
Does anyone have solutions for this? I'd love to hear them !
Regards,
Niels
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
Quote:AD will slow it down
Thats normal
Kinda sorta. Basically, a server running AD can run almost as fast at boot up and shut down as most member servers. The big issue here is that Domain Controllers (since NT 4.0) have always needed at least one counterpart in the domain to operate efficiently. This stems from the constant communication that a DC wants to do during startup to validate the network that it is coming up into and shutting down from (Browse Master, WINS host, etc). This is further complicated with AD since there are more functions to track and register with ((D)DNS, WINS, Browse Master, Time Source, etc) during startup and shutdown. In addition, policy configuration has a *major* impact on this. If you have aggressively configured logging either locally or via templates (such as logging all successes and failures in all security objects) you can greatly impact not only startup, but shutdown time. We are testing templates right now that are highly aggressive (modded NSA-based templates) and these cause our DCs to take about 12 - 15min to shutdown. All these servers do is host FSMO roles, and don't have any applications installed at all (besides AV and AD monitoring agents) and yet they are slower than anything else I have used. These templates also generate logs that are so large that they require at least weekly (typically daily) removal via some automation tool in production.
So, in some vague order, here are the major things that slow down the system:
Bringing up the network - This can be an issue since the server will need to register itself against a DDNS server on the network (unless specified not to via a reg tweak). If this box is the only DC, this may not occur properly if the processes are running in asynchronous mode and there are no dependencies declared on the local DNS service to start up before the server tries to register itself. One major help for this is to make sure that all the DDNS servers have their local IP address (the IP that is answering DNS queries) entered into their primary DNS server position in their local IP settings. By having a second DC with DNS on the network, the server can move to the second one during boot since the local DNS service may not have started in time to answer its own request (kind of like needing to be awake before you can answer a phone call; if you are a sleep you can't answer the phone in time but if another person is around they can do that for you and vice-versa). This second DC can also host the Browse Master service and turn over control if the starting DC is also hosting WINS (not needed in a modern AD network unless you have legacy applications, such as Microsoft Exchange 2000 or earlier, that still use NetBIOS name resolution). Properly configured DDNS will reduce the boot time and make it run a lot smoother.
Services - Since a "server" will have more services, this will slow down launching of the system. In addition, many of the services will require authentication, and if the server can't register itself on the network and get the NETLOGON service started fast enough, there will be a noticable delay in the other services getting authenticated and therefore started. Again, this is alleviated with a second DC on the network that can field these calls and let the system get everything running in a timely manner.
Template Application - As mentioned earlier, improperly configured templates for your hosted environment can greatly impact startup performance. Set them as needed to strike the proper balance between security and performance. In addition, the server will scan its local AD DB to make sure that it is by itself (the only DC) on the network. If it finds that there are others, it will want to converse with them about account and template consistency (for example, does it have the newest version of all the accounts and templates).
Hope this explains it somewhat.
Thats normal
Kinda sorta. Basically, a server running AD can run almost as fast at boot up and shut down as most member servers. The big issue here is that Domain Controllers (since NT 4.0) have always needed at least one counterpart in the domain to operate efficiently. This stems from the constant communication that a DC wants to do during startup to validate the network that it is coming up into and shutting down from (Browse Master, WINS host, etc). This is further complicated with AD since there are more functions to track and register with ((D)DNS, WINS, Browse Master, Time Source, etc) during startup and shutdown. In addition, policy configuration has a *major* impact on this. If you have aggressively configured logging either locally or via templates (such as logging all successes and failures in all security objects) you can greatly impact not only startup, but shutdown time. We are testing templates right now that are highly aggressive (modded NSA-based templates) and these cause our DCs to take about 12 - 15min to shutdown. All these servers do is host FSMO roles, and don't have any applications installed at all (besides AV and AD monitoring agents) and yet they are slower than anything else I have used. These templates also generate logs that are so large that they require at least weekly (typically daily) removal via some automation tool in production.
So, in some vague order, here are the major things that slow down the system:
Bringing up the network - This can be an issue since the server will need to register itself against a DDNS server on the network (unless specified not to via a reg tweak). If this box is the only DC, this may not occur properly if the processes are running in asynchronous mode and there are no dependencies declared on the local DNS service to start up before the server tries to register itself. One major help for this is to make sure that all the DDNS servers have their local IP address (the IP that is answering DNS queries) entered into their primary DNS server position in their local IP settings. By having a second DC with DNS on the network, the server can move to the second one during boot since the local DNS service may not have started in time to answer its own request (kind of like needing to be awake before you can answer a phone call; if you are a sleep you can't answer the phone in time but if another person is around they can do that for you and vice-versa). This second DC can also host the Browse Master service and turn over control if the starting DC is also hosting WINS (not needed in a modern AD network unless you have legacy applications, such as Microsoft Exchange 2000 or earlier, that still use NetBIOS name resolution). Properly configured DDNS will reduce the boot time and make it run a lot smoother.
Services - Since a "server" will have more services, this will slow down launching of the system. In addition, many of the services will require authentication, and if the server can't register itself on the network and get the NETLOGON service started fast enough, there will be a noticable delay in the other services getting authenticated and therefore started. Again, this is alleviated with a second DC on the network that can field these calls and let the system get everything running in a timely manner.
Template Application - As mentioned earlier, improperly configured templates for your hosted environment can greatly impact startup performance. Set them as needed to strike the proper balance between security and performance. In addition, the server will scan its local AD DB to make sure that it is by itself (the only DC) on the network. If it finds that there are others, it will want to converse with them about account and template consistency (for example, does it have the newest version of all the accounts and templates).
Hope this explains it somewhat.
