If this is the case let me know I will tell you the facts!!!
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.
10. You can deploy this MSI file (that is the configuration of DHCP Client) using Group Policy Software Installation snap-in.
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.
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:
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.
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.