November 2006 - Posts
If this is the case let me know I will tell you the facts!!!
Its time to play guitar with Bryan.....
How do you feel now :)
You might have few questions to yourself:
1. Why domain GPO will still apply to local admin account of client computer.
2. Why domain GPO will still apply in safe mode and safe mode with networking modes.
Interesting when you see domain GPO will still apply to a computer not connected to network.
This behaviour is by design. This is just to maintain the security of computer.
The reason and Logic behind this
Its all about the Computer Account and relationship of client computer with domain. Windows OS and Winlogon service still assumes that a PC logged on to local computer or safe mode/with networking is the member of domain as long as Computer account of this local computer exist in domain or a secure channel exists between computer and Domain Controller.
Windows OS assumes that the security of this computer should be maintained by a domain controller as long as it is the member of the domain. So GPOs will be applied when you log in Safe Mode or any other mode.
This article explains about the garbage collection process used by AD to clear out orphaned objects from AD Data (ntds.dit).
Windows 2000/2003 deletes all tombstone objects after 60 days after their original status. AD sets isDeleted attribute to TRUE after the 60 days automatically or when you delete an object manually. This is because a tombstore should be replicated to all domain controllers in the domain (The domain partition). Otherwise objects will be re-created in AD.
You can also change the default time.
If you want to change the default time you can modify the tombstonelifetime setting under cd=DirectoryServices,cn=WindowsNT,cn=Services,cn=Configuration,dc=DomainName parameter which i don't recommend.
Each directory partition holds a container called Deleted Object except Schema partition because you can't delete objects from this partition. After deleting an object or setting isDeleted attribute to TRUE AD moves these records to Deleted Object container in the partition that contained the object.
AD hides these Deleted Objects containers by default, so to view them you must enable the Return Deleted Objects Lightweight Directory Access Protocol (LDAP) control as part of a search operation.
You can search Tombstone objects using LDP found in Windows 2000 and Windows 2003.
Microsoft has already published an article to change Static IP address to DHCP over the network. One day I had to fight with this situation. I had to change all static clients to DHCP-aware using the article published at Microsoft support site: http://support.microsoft.com/kb/q194407/.
In deed, the above article is useful but it requires a lot of manual effort. You need to connect every computer through "Remote Registry API" and then change the required detail in regsitry for all computers - so the pain!
This is lengthy task when you need to do the manual work on more than 100 computers.
I have pointed out a solution for situation for network administrators who fight against manual process.
I have found the following ways to do so:
1. Using WININSTLE you find the registry keys for DHCP Client machine when they obtain IP Address automatically from DHCP Server.
2. Using PSEXEC (if you're network is in Workgroup Security Model) or Group Policy (If you're in Domain Security Model) to deploy DHCP Client settings remotely with a text file pre-configured which can be used to differenciate between IP addresses used by client machines.
You need to install and run WinInstLE on one of your client computer.
1. Goto a client machine.
2. Install WININSTLE. This utility is located at Windows 2000 CD.
3. Run WININSTLE. Perform *Before Snapshot* operation.
4. Give a path to save MSI file and registry informations.
5. Restart client computer.
6. Configure client machine to obtain IP address automatically from DHCP Server.
7. After restarting client computer, run *After Snapshot*. This will record any changes made during the operation DHCP Client contacted and got IP Addrss from DHCP Server.
8. Edit the *.REG file and delete the IP Address it got from DHCP Server. This will make sure that all the client computers use unique IP Address on network. Save this file.
9. Now you have two files to deploy either using PSEXEC or Group Policy.
MSI file
REG file
10. You can deploy this MSI file (that is the configuration of DHCP Client) using Group Policy Software Installation snap-in.
OR
You can deploy this MSI file or REG file using PSEXEC remotely on all client computers. By using PSEXEC you can specify a text file which keeps informations about the IP Address+Client computer name.
Now you need to put everything together to get things working. This is how you do it: -
NOTE: The only unique filed required in DHCP Configuration is IP Address.
1. You have got a REG file with you from WININSTLE. Edit this REG file and remove the IP Address value. I think you have already done in above steps.
2. Save this REG file.
3. Copy the full MSI folder to server from where you want to deploy DHCP settings.
4. Deploy this MSI file using Software Installation snap-in.
5. After deploy MSI file all configuration settings will be saved in all client computers except IP Address.
6. Next client computers will restart and obtain IP Address from DHCP Server.
NOTE: If you want to enable DHCP for other connection specify the name of connection in netsh command.
netsh interface ip set address "Local Area Connection" dhcp
This should work well.
SUMMARY: -
The following is required for client to be a DHCP Client when configuring manually
DHCP Client service should be started.
Client LAN connection should be set to *Obtain IP from DHCP Server*.
netsh interface ip set address "Local Area Connection" dhcp
DHCP Client must have a unique IP Address on network.
Some registry entries as described in the above article must be set.
HKLM\SYSTEM\CurrentControlSet\Services\XXXXXX\Parameters\TCPIP, where XXXXXX is the value of ServiceName found in the step 3 in the above article.
EnableDHCP = 1
IPAddress = 0.0.0.0
SubnetMask = 0.0.0.0
DHCPDefaultGateway = 192.168.0.1 -- If you are using some other gateway then you need to put it in script or manually in registry.
DHCPIPAddress = 192.168.0.5 --- IP got from DHCP server.
DHCPServer = 192.168.0.1 -- IP Address of DHCP server.
You don't need to restart workstation. Simply restart DHCP Client service on destination computer using a script.
Let's say you want to implement a policy setting that can be used to close off all the programs running in computer.
Actually speaking this is not bit easy but you can deploy a script that can do your job at specifed time using Task Scheduler service.
To accomplish above you need the followings:
1. A startup or logon script.
2. tlist.exe to display list of processes running on the computer and kill.exe to kill the processes running except Windows defaults.
3. AT command to schedule the script at specified time.
You need to know the *process name* of the application you want to close or kill. You can use resource kit tool called "kill.exe* to close the process of an application. When you kill the process, application will be closed automatically.
You need to run a script using Group Policy which will run at 10.00 PM everyday. You can achieve using Task Scheduler service or using AT command in a script. Deploy this script using Group Policy.
Files opened by network clients must also be closed in order to perform backup. You can use the command outlined here to close all opened files by network users.
Please follow this article:
http://support.microsoft.com/?kbid=290585
If you don't know what all applications clients are running then you need to use some kind of programming stuff which can identify and close the application. Likewise all running applications can be closed by killing the main process that is Explorer.exe. But if you kill explorer.exe then you need to re-run it in order to perfrom backup. Using some programming stuffs you can acheive this. Here is an example:
1. You create a script.
2. Use kill.exe in this cript to end PID of explorer.exe or kill this process.
3. Run a command again to re-start this process (explorer.exe) to lunch desktop and then perform backup.
Have you ever wondered? creating a disaster recovery plan for Roaming profiles without clustering. This is really interesting when someone wants to switch over Roaming profile in a network where one of DC is failing and other DCs are alive to serve the requests.
Scenario:
Let's say you have two 100 client computers in your network and two domain controllers named: DC1 and DC2. All users have been configured with roaming profiles setup on DC1 and DC2. These users frequently log on to DC1 and switch over to DC2 in case of failure.
For some reasons, you want to create a disaster recovery plan for Roaming users - you want these users to switch over to DC2 and retreive their roaming profile from DC2 in case of DC1 failure.
Setup seems not so easy! but this is how you do it actually:
You need a startup script and deploy this script using Group Policy throughout the network.
This disaster recovery plan for romaing profiles can be designed by creating a Windows startup script. LOGONSERVER environment variable is common between these two DCs. You just need to set this in your script so that when script starts it should read the authentication server name and set in user's property using LDIFDE tool.
You can see LOGONSERVER by typing SET command at command prompt. This tells by which DC this client was authenticated.
In the above scenario clients roaming profile are located at DC1.
1. Client starts
2. Netlogon finds a suitable domain controller for the client.
3. Sets the Environment variable: LOGONSERVER to the DC is about to authenticate client.
4. Startup script runs.
5. This script checks the path of Roaming profiles from the user's property using LDIFDE tool.
6. Script pings the domain controller (let's say client is configured to use romaing profiles on DC1 and DC2 is supposed to authenticate client in this regard.)
7. Script gets a "Request Timed Out" message from DC1.
8. Script assumes that this domain controller is not available on the network.
9. Then it takes the DC name from the LOGONSERVER environment variable and sets this LOGONSERVER in user's property and in registry as well : \\DC2\profiles\%username%.
10. Netlogon passes control to Winlogon service.
11. Winlogon finally allows client to log on to computer.
12. Client logs on to computer. His profile path is checked and roaming profile is loaded from DC2 directly.
13. So in this case no failure is noticed.
Keep the following rules in mind before you apply the Group Policies:
1. Group Policies can be applied to AD-Leaf objects such as users and computers but NOT security or distribution Group.
2. Users and Computers MUST reside in the OU where you have configured Group Policy.
3. Group Policies can use GROUPS to filter the scope of policy settings.
4. By default Group Policies are applied to the following groups:
Authenticated Users
5. If the security properties are default....then Group Policy settings should apply to administrators or you because by default when you create a GPO the following Security Settings permissions are set:
*Apply Group Policy* and *Read* Permission to the following Groups:-
Authenticated Users
Domain Admins
Enterprise Admins
Administrators.
5. Group Policy processing depends on Client-Side-Extensions stored in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPTExtensions << all GUID listed for Client-Side-Extensions.
CSCs are used to process GPOs from Domain Controller. Winlogon.exe will capture a list of GPOs.
As per M$ recommendation you should remove *Authenticated Users* group and create a new Group > add all members to this group and use FILETERING technique. Now generally what happens all user objects are member of
Authenticated Users Group and the settings are mixed because from Domain Level to.........child OU the settings are applied to Authenticated Users Group.........so for example :-
If you have configured anything in the parent OU and also configured in Child OU...and all users are member of Authenticated Users Group....settings are meesed up and then Group Policy rule is applied:
Policy Settings at Parent OU Policy Settings at Child OU Result
If NOT Configured If Configured Child's setting applied
If Configured If Configured and Do not conflict Both Settings
If Configured If Configured and Conflicts Child's setting applied
If Configured If Not Configured Parent's Setting applied
If NOT Configured If Not Configured No Settings (This is default)
By default, only the first domain controller or so-called Root domain controller and finally so-called "PDC Emulator" is configured to be a Reliable Time Source.
If it doesn't exist you need to create it to make it ReliableTimeSource for other client computers and domain controllers.
Let me explain something:
By default client machines use *default heirarchy" to synchronize time. Clients will only sync with their own domain controllers in the domain. This is default bahviour and by design and to keep time closer between all PCs.
PDC is the 2nd highest stratum. Client will try to sync time with their own domain controller *unless* specifically you specify to do so. Becuase PDC is configured an authoritative server by default. It is configured using *ReliableTimeSource" entry in registry.
Stratum:
1 External NTP time source
2 PDC emulator of the forest root domain
3 Domain controllers in the forest root domain or PDC emulators in child domains
4 Workstations and member servers in the forest root domain or domain controllers in child domains
5 Workstations and member servers in child domains
Computers choose a time source according to a specific order of preference. This order, from most preferred to least preferred. The following table displays the preferences for Selecting a Time Source:
Preference Computer Location Reliability of Time Source
1 Parent domain controller In-site Reliable
2 Local domain controller In-site Reliable
3 Parent domain controller In-site Not reliable
4 Local PDC emulator In-site Not reliable
5 Parent domain controller Out-of-site Reliable
6 Local domain controller Out-of-site Reliable
7 Parent domain controller Out-of-site Not reliable
8 Local PDC emulator Out-of-site Not reliable
There is nothing much you need to do with *ReliableTimeSource* entry in registry. Simply edit the value and set it to 1 to make it Reliable time source for all computers in your network.
Moreover, you can also configure your PDC or Root Domain Controller to sync with hardware as a source time server but it is recommended that you configure your PDC to sync with an external time source.
How to configure an Authoritative Time server in Windows 2000:
http://support.microsoft.com/kb/q216734/
The DNS which ships with Windows 2000/2003 server.
Advantages:
1. DNS supports Dynamic registration of SRV records registered by a Active Directory server or a domain controller during promotion. With the help of SRV records client machines can find domain controllers in your network.
2. DNS supports *Secure Dynamic updates*. Unauthorized access is deniend.
3. Exchange server needs internal DNS or AD DNS to locate Global Catalog servers.
4. AD-Integrated Zone. If you have more than one domain controller (recommended) you need not worry about zone replication. AD-replication will take care of DNS zone replication also.
5. If you use DHCP with AD no other DHCP will be able to service client requests comming from different network. It's because DHCP server is authorized in AD.
Moreover, you can use NT4 DNS with Service Pack 4 or later. It supports both SRV and Dynamic Updates.
So for BIND DNS you must be running atleast 4.9.7 version which supports SRV and meets the minimum requirements for Active Directory Support. However, BIND 8.2.1 and later support dynamic updates and incremental zone transfers, in addition to the SRV records.
Based on the tests performed by various vendors and Microsoft, the recommended BIND version that proves to work best with Active Directory is BIND 8.2.2. Keep in mind that BIND DNS servers do not support Active Directory integrated zones----So basically this is the difference between using MS DNS and External DNS to support Active Directory. In addition to SRV and Dynmaic Support, replication is also effected if you create an AD-Integrated Zone which can replicate with Directory Replication and no overehead of planning for DNS Replication. BINDs are limited to primary and secondary zones.
So using MS DNS gives the following benefits: -
If you implement networks that require secure updates.
If you want to take benefit of Active Directory replication.
If you want to integrate DHCP with DNS for Low-level clients to register their Host records in MS DNS.
MS support for DNS is better than external DNS servers.
Many articles have been written on MS DNS+Active Directory (Troubleshooting articles)
Have a look at these articles:
Active Directory design consideration:
http://www.windowsnetworking.com/articles_tutorials/Active-Directory-Design-Considerations-Small-Networks.html
DNS and Active Directory:
http://www.windowsitpro.com/Windows/Article/ArticleID/21128/21128.html
Securing DNS by design:
http://www.windowsecurity.com/articles/Securing_Windows_2000_DNS_by_design_Part_1.html
Frequently asked questions about DNS
http://support.microsoft.com/kb/291382/
Here is a complete list of articles for delegating controls to admins:
You can delegate permissions to junior Admins using MMC Taskpads.
How to use Adminpak.msi to install a specific server administration tool in Windows
http://support.microsoft.com/?kbid=314978
HOW TO: Delegate Administrative Authority in Windows 2000
http://support.microsoft.com/?kbid=315676
HOW TO: Create and Edit a Taskpad View in a Saved MMC Console in Windows 2000
http://support.microsoft.com/?kbid=321143
Default Security Concerns in Active Directory Delegation
http://support.microsoft.com/?kbid=235531
Delegate Control Wizard Cannot Be Used to Remove Groups or Users
http://support.microsoft.com/?kbid=229873
Administrative Tool Menu Is Sensitive to User's Permissions
http://support.microsoft.com/?kbid=214739
In a Server 2003 domain, you can ignore the part about editing dssec.dat:
How To Delegate the Unlock Account Right
http://support.microsoft.com/?kbid=294952
A must read for Domain Administrators:
Design Considerations for Delegation of Administration in Active Directory
*Achieving Autonomy and Isolation with Forests, Domains, and Organizational Units*
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/addeladm.mspx
Using scripts you can set delegation on properties if you want:
Part 1
http://www.microsoft.com/technet/scriptcenter/topics/security/exrights.mspx
Part 2
http://www.microsoft.com/technet/scriptcenter/topics/security/propset.mspx
You can find security attributes for each object in Chapter -6 of *Inside Active Directory-Second Edition*
Here it is: An online version of this book.
http://www.readol.net/books/computer/Windows/Inside.Active.Directory.A.System.Administrators.Guide.Second.Edition/0321228480/ch04lev1sec3.html
Scenario:
ISTG has invalid on all Domain Controller on the network after you demote a DC and trasfer roles and then rebuild it.
If demoted Domain Controller is the first DC in site - If yes then this DC holds the role - ISTG Server.
Initially the first server in the site becomes the ISTG owner and this this role is communicated by normal AD replication.
Moreover, this role is not changed automatically. Server holding ISTG role notifies other domain controllers about its presence by writing the *InterSiteTopologyGenerator* attribute in Configuration Naming Context at a specified interval.
Another fact is that another DC as an ISTG server doesn't take over unless it knows that DC hold ISTG server has failed.
To correct this issue:
You can edit the following registry value to modify this behaviour:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Value Name: KCC site generator renewal interval (minutes)
Value Data: Number of minutes between updates to Active Directory
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Value Name: KCC site generator fail-over (minutes)
Value Data: Time that must elapse before a new ISTG is selected, in minutes.