1. create ma partition by using disk utility or command prompt (i.e /dev/sda10)
2. Do no mount this as it will take more time to copy.
3.
dd if=/dev/sda9 of=/dev/sda10
1. create ma partition by using disk utility or command prompt (i.e /dev/sda10)
2. Do no mount this as it will take more time to copy.
3.
dd if=/dev/sda9 of=/dev/sda10
Most of you reading this will already know what DNS Scavenging is. For those of you that don’t it is a feature of Windows DNS servers which allows you to automate the deletion (scavenge) of outdated DNS resource records. It sounds simple enough and it is once you decipher Microsoft’s cryptic descriptions, but to the uninitiated it is just plain confusing and often leads to unpredictable results. This article will attempt to simplify how DNS scavenging works.
Enabling DNS Scavenging on Zones
The first thing we need to do is enable Scavenging. This is done separately for each DNS zone. To enable scavenging on all zones see “Enable Scavenging on All Zones” below. To enable scavenging right click the DNS zone, select properties and then on the general tab select the “ageing” button.
Tick the box “Scavenge Stale resource Records” and leave the rest to their defaults.
Here is where the confusion starts. The No-Refresh and Refresh Intervals are not when resource records get scavenged. They are timers for when DNS records become eligible for scavenging. The actual scavenging process is done elsewhere.
Enable Scavenging on All Zones
To enable scavenging for all zones right click the DNS server name and select “Set Ageing/Scavenging for all DNS zones”
It is important to point out that this will only enable scavenging on NEW zones. To apply it to existing zones tick the box (on next pop-up) that says “Apply these settings to the existing AD zones”.
No-Refresh and Refresh Interval Settings
DNS clients by default update their DNS resource records every 24 hours. There are two ways to do this. If the client’s IP has changed since the last update it is considered an “update”. If the IP hasn’t changed then it is considered a “refresh”. In both cases a new timestamp is set.
The No-Refresh interval is the amount of time after the timestamp where the DNS server will not accept a “refresh” from the client. Apparently the point of this is to cut down on DNS replication if you have multiple DC’s; it makes sense, I mean what is the point of updating the record with a new timestamp and causing unnecessary replication traffic if nothing else has changed? By setting the No-refresh interval you prevent these refreshes from taking place causing less replication. Non refresh updates (where the IP changes) can update the record at any time.
The Refresh interval starts AFTER the no-refresh interval. In this window updates and refreshes are allowed. If a resource record hasn’t been updated by the time the no-refresh and refresh intervals have elapsed it becomes eligible for scavenging. The no-refresh and refresh intervals are cumulative (that is 14 days in the image above).
Let’s look at an example using the settings above. My PC has an IP address of 192.18.0.1 and registers this with my PC name on the DNS server. It will now contact the DNS server every day to update or refresh the DNS record depending on whether my IP changes or not. For the first 4 days my IP is the same which means each day it tries to “refresh” the DNS record. The DNS server does not allow this due to the No-Refresh interval of 7 days. On the fifth day my IP changes so my PC tries to “update” the DNS record. The server allows this as the no-refresh interval doesn’t apply to “updates”. The record is updated along with a new timestamp and the no-refresh period starts again. Now 7 days pass where my IP hasn’t changed. After 7 days the DNS server allows me to “refresh” the record setting a new timestamp and we enter the no-refresh interval again. If 14 days pass without the record being updated or refreshed the record becomes eligible for scavenging.
Scavenging Records
The above steps only enable DNS scavenging on the zone. To actually scavenge stale resource records you right click the server and select “Scavenge stale resource records”. The server will then delete records with timestamps older than the No-Refresh interval plus the Refresh interval. With the default settings this is 14 days. To enable automatic scavenging right click the server, select properties and then click the Advanced tab.
Tick the box that says “enable automatic scavenging for stale records” and set how often you’d like it to run. Each time the scavenge process runs whether you initiate it manually or automatic it is recorded in the Windows event log with ID 2501/2502. For Windows 2003 servers this is in the system event log, for 2008 it is in the DNS event log. This is important as it should be the first place you look if you suspect scavenging isn’t working; it ALWAYS logs this when scavenging takes place, if there is no entry then scavenging failed and you need to investigate why.
TIP: To work out when automatic DNS scavenging will run next find the most recent 2501/2502 event and add the scavenging period to it.
Other Reasons Why DNS Scavenging May Fail
If you already knew all the above it is likely you have been caught out by the following:
The server is not authorised to perform scavenging on this domain – This was the cause of my scavenging issues; a good indication of this is that there are no 2501/2502 events logged when you run scavenging. To my knowledge there is no way to determine which servers are authorised to scavenge but you can reset this if unsure. To reset it and allow DNS scavenging on only the servers you specify type “DNSCmd . /ZoneResetScavengeServers yourdomain [list of DNS server IP addresses]” at a command prompt. If I had two DNS servers I want to authorise scavenging for on mydomain.local with IP’s 192.168.0.1 and 192.168.0.2 I would type DNSCmd . /ZoneResetScavengeServers mydomain.local 192.168.0.1 192.168.0.2. You should now try scavenging again and this time you should see an event logged for it. Scavenging may still fail however for the next reason.
The no-refresh interval hasn’t yet elapsed since enabling the zone for scavenging – When you first enable a zone for scavenging ALL DNS records are protected until “The zone can be scavenged after” date has passed regardless of their timestamp.
This to allow ample time for DNS records and timestamps to be updated on all DNS servers. For those of you wondering how this calculated it is the date you enabled DNS scavenging plus the no-refresh interval. If you do not see this section close the window and refresh the zone. When you open it again it should be there. If it still isn’t there it maybe because you have an SBS server or single DNS server environment in which case no replication occurs so this setting is irrelevant and does not apply to you.
Putting It All Together
Here is one last example which takes into account everything discussed above.
After we enable DNS scavenging on the zone we immediately run a manual scavenge but notice that the records with timestamps older than 01/04/12 haven’t been deleted. We check the DNS event log and see that no DNS scavenging events have been logged so we run the ZoneResetScavengeServers command to authorise our DNS server to scavenge this zone. We then run scavenging again but it still fails to delete any records. We note that this time events have been logged so we know a scavenge has taken place. We check the “This zone can be scavenged after” and note that the date is set to 29/04/12 which is exactly the current date plus the no-refresh interval. This means the zone is protected from scavenging until th 29th and no DNS records can be scavenged until then. We come back on the 29th and see that the records over a month old are still there. This is because although the zone can now be scavenged the next scavenge attempt will not occur until exactly 4 days after the last scavenge was run; since we ran one on 26/04/12 the next would be 30/04/12. We run a manual scavenge again and note that 01/04/12 and older records have now been deleted. On the same day (29th) we notice that the record our client created on the 28th still has a timestamp set as 28th, this is because it’s IP address hasn’t changed and attempts a refresh but the no-refresh settings prevent it from doing so for 3 days. On the 01/05/12 the PC is shut down and decommissioned. 01/05/12 is still in the no-refresh interval (for this record only) so it never refreshed it’s resource record and still has a timestamp of 28/04/12 (note: if the IP had changed it would have updated the record and timestamp). On 05/05/12 the client’s record is now eligible for scavenging as 3+4 days have elapsed since the timestamp. The record will be deleted if we run another manual scavenge or automatic scavenging runs on 07/05/12 which is exactly 4 days after the last scavenge ran.
Note: It is the 7th because the last automatic scavenge would have happened on 3rd (which I didn’t mention above) which is 4 days after our manual scavenge on 29th.
We can enable remote desktop from windows command line by running the following command.
reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server” /v fDenyTSConnections /t REG_DWORD /d 0 /f
To disable remote desktop we need to run the below command.
reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server” /v fDenyTSConnections /t REG_DWORD /d 1 /f
To enable Remote assistance:
reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server” /v fAllowToGetHelp /t REG_DWORD /d 1 /f
If you Google “the trust relationship between this workstation and the primary domain failed”, you get plenty of information from support blogs and Microsoft articles; however, most of them ask you to rejoin your machine to the domain. That’s not always possible.
The underlying problem when you see this error is that the machine you are trying to access can no longer communicate securely with the Active Directory domain to which it is joined. The machine’s private secret is not set to the same value store in the domain controller. You can think of this secret as a password but really it’s some bits of cryptographic data called a Kerberos keytab stored in the local security authority. When you try to access this machine using a domain account, it fails to verify the Kerberos ticket you receive from Active Directory against the private secret that it stores locally. I think you can also come across this error if for some reason the system time on the machine is out of sync with the system time on the domain controller. This solution also fixes that problem.
This problem can be caused by various circumstances, but I most commonly run into it when I reset a virtual machine to a system snapshot that I made months or even years before. When the machine is reset, it is missing all of the automatic password changes that it executed against the domain controller during the intervening months. The password changes are required to maintain the security integrity of the domain.
Support blogs and Microsoft will generally tell you to rejoin the domain to restore the trust relationship. Another option they will give is to delete the computer object and recreate it without a password and rejoin.
Microsoft support article on the topic: http://support.microsoft.com/kb/162797
I’m not a fan of any of these options. This seems heavy handed and sometimes they aren’t even possible.
Recently, when I ran into this problem, the virtual machine that reset was an enterprise certificate authority joined to my test domain. Well, guess what, Microsoft will not allow you to rename or unjoin a computer that is a certificate authority—the button in the computer property page is greyed out. There may be another way to unjoin but I wasn’t going to waste time on it when it isn’t even necessary.
Just change your computer password using netdom.exe!
netdom.exe resetpwd /s:<server> /ud:<user> /pd:*
<server> = a domain controller in the joined domain
<user> = DOMAIN\User format with rights to change the computer password
Here are the full steps:
Here is more information on netdom.exe: http://support.microsoft.com/kb/325850I hope this is helpful. This problem comes up every few months for me, so I wanted to document it for my own use. It is difficult to find when you just search for the error you get in the login window.
My Note
Above solution never tried by me but seems to be effective. Durjoy
Some Effective Discussion
Thank you so much. We had an issue where our local admin password was unknown. We unplugged from the network and we back up and running in three min. Thank you so much for this article.
First reasonable conclusion I have seen over the standard “Unjoin then rejoin the domain” this changes the SID people and any trust relationships you had with this server or shared resources you had to this server change if you unjoin and rejoin! I will try this out next time I have to restore one of my VM’s as this is when we run into a problem.
One question: Can this command be issued to the machine that can’t login to the domain from a machine that is on the domain? Just a thought since netdom.exe will execute commands to remote computers.
Hmm… I haven’t tried to issue the command to remote computers. It would be nice if it did work. Could be problems depending on how you are authenticated when the trust relationship is broken down… If it does work, please post a comment.
You need to use a different netdom command to run remote:
NETDOM RESET machine [/Domain:domain] [/Server:server] [/UserO:user] [/PasswordO:[password | *]]
This way you can define the remote machine name and the user name and password of the remote machines local administrator account (or any other local account with administrative rights of course)
After reading this article to get an idea of what exactly had transpired with a machine, I signed on as a local administrator, used System Restore to restore a more recent restore point. Thanks for the pointers! great article.
Your solution is AWESOME! Thanks it worked for me too. I also recently reset my machine into a system snapshot which was build 2 weeks ago! Another problem that I have with this is VPN connection! It also didn’t work but after using your solution it works.
Hi everyone
Far simpler way to do is by clicking the network ID wizzard, select the (this computer is part of a business network and use it to connect to other computers at work) and click next, click on my company uses a network with a domain and click next and next again then type the administrator user name and password, choose the option to (not create a new user) and finish/apply. You will now be able to log in again.
Regards.
German
logged in to say thanks, it worked. The scenario is this, we wanted to move to a new server and we had lots of users connected to the domain, after logging into the new server which had exactly same IP, Name and etc, we were getting this error, and now its fixed.
Top class article, thanks for the tip, saved a great deal of time
I’ve been finding the machine name in AD and right-clicking > ‘reset account’
…that seems to do the trick in 1 of 1 test case for me on our domain.
Doesn’t work for me – netdom fails with “The specified domain either does not exist or could not be contacted”.
Check your DNS configuration. Try running: nslookup <domain name=”">
Check your network configuration. Try running: ping <domain address=”" controller=”" ip=”">
I am guessing that you really can’t resolve the domain name or the IP address of your domain controller is just unreachable.
Dan</domain></domain>
I have the same problem… But i cant log in My local admin account bcz. i forgot it it,, any one can help me to do this..
You are the one! Thanks for this very helpful solution! This is exactly what I was looking for! In my case the VM restored to an earlier checkpoint are running a failover cluster, so unjoining the domain was not an option!
Thank you again!
Ops. Dealing with clusters is not so easy! Now I restored the trust relationship between the cluster nodes and the domain, but there is still something broken with the computer account of the cluster name. I tried something with netdom and the cluster name as if it was another computer name, but it is not working…
Any idea?
If it could help anyone else, I found out a very simple solution! On the cluster manager itself, on the cluster name, just right-click and select Repair Active Directory Object, and it did the trick!
xp to 2008 r2, ran the netdom cammand as suggested and recieved following error: the machine account password for the local machine could not be reset. Insufficient system resources exist to complete the requested service. -help?
Thank you – works very well!
Wonderful, simply wonderful….
Thanks Dan for not only finding a good solution but also putting it on the Internet with a clear title (DONT REJOIN TO FIX..etc).
@Gata: go to www.microsoft.com/download and search for RSAT, download and install the version appropriate for the desktop OS you’re running.
What do you do if NETDOM is not on the computer trying to get on the domain? When I did a search for NETDOM on Windows 7 I found articles about the new Windows Powershell.
Gata, go to www.microsoft.com/download, search for RSAT, and download/install the version for the desktop OS you’re working with. Be advised that the Win 7 toolkit is about 300MB
Fixed my problem in seconds, also caused by reverting to a VM snapshot. I can’t restart the OS due to unrelated reasons, so I was starting to wonder how the hell I’d get it back on the domain.
Thanks a lot for your solution… Why doesn’t MS even suggest such a fix that is working 100% ?
Thanks again
Thanks for the info. This is what we do, dis-join and re-join everytime the issue raise. irritating when the server is in production which needed restart.
Just would like to assure, is this the 1 time solution for the issue?
Thanks.
This post was really helpful! Thanks for taking the time to write it.
Thank You!! I ran into this issue after cloning one of my VM’s. could not get them on the domain.. this did the trick
This worked great! I’m using PVS 6.1 to stream XenApp 6.5 servers. PVS is supposed to handle password updates automatically for machine accounts. But from time to time when creating new vdisks and the vdisks are in private mode (master or update machines) I get this domain trust error.
This worked like a charm. Thank You. Tried to get IT Admin to resolve this issue with one of my VMs that prevented me from going to the …\C$ drive from my desktop for MONTH finally googled error myself and ran your solution.
1. Edit the file
vi /etc/yum.repos.d/server.repo
[base]
baseurl=file:///media/RHEL_6.2\ x86_64\ Disc\ 1/
gpgcheck=0
enabled=1
2. Now use yum to install/remove/search from cd/dvd
i.e yum install tigervnc* -y
Be noted that after finishing job you must change in file otherwise yum will not look in online repository
First Create bridge file
cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-br0
Edit main ethernet file
vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=”eth0″
NM_CONTROLLED=”no”
ONBOOT=yes
TYPE=Ethernet
BRIDGE=br0
BOOTPROTO=none
PREFIX=24
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME=”System eth0″
UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
HWADDR=34:40:B5:AC:4D:10
3. Edit bridge file
vi /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=”br0″
NM_CONTROLLED=”no”
ONBOOT=yes
TYPE=Bridge
BOOTPROTO=none
IPADDR=10.37.100.207
PREFIX=24
GATEWAY=10.37.100.1
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
4. Editing fininsh.
5. service network restart.
Be noted that when using bridge ten network manager must be off otherwise problem will be occure. In case if you dont want to stop network manager then add one line (NM_CONTROLLED=”no”) in both/all interface files which are using bridge (include bridge file like above.). IN this case network manager will not interfere for these interface file.
Another thing to be conside that IP will only be given in bridge file. Sometimes after bridging system require restart.
#Note: Following code will run in Powershell. The code will display ouput list of computer objects which didn’t login to domain for last 180 days. Be noted that by default each computer object set its password when it join to domain and change their password in each 30 days. So any running computer’s password change duration should not greater than 30 days. For safty (which is also norm) we can say any computer did not change its password for 180 days can be treated as obsolte object in Active directory.
#Tested Platform : Windows Server 2008 R2 Standard
#Changes can be made :At last line number 180 can be changed to get user required desire output. i.e : Need obsolete computer object which did not change password for last 60 days. Replace 180 by 60.
Output: Output will display in screen and also save in text file of current directory
CODE:
cls
function Get-DomainComputerAccounts
{
# Use Directory Services object to attach to the domain
$searcher = new-object DirectoryServices.DirectorySearcher([ADSI]“”)
#Leaving the ADSI statement empty = attach to your root domain
# Filter down to computer accounts
$searcher.filter = “(&(objectClass=computer))”
# Cache the results
$searcher.CacheResults = $true
$searcher.SearchScope = “Subtree”
$searcher.PageSize = 1000
# Find anything you can that matches the definition of being a computer object
$accounts = $searcher.FindAll()
# Check to make sure we found some accounts
if($accounts.Count -gt 0)
{
foreach($account in $accounts)
{
# Property that contains the last password change in long integer format
$pwdlastset = $account.Properties["pwdlastset"];
# Convert the long integer to normal DateTime format
$lastchange = [datetime]::FromFileTimeUTC($pwdlastset[0]);
# Determine the timespan between the two dates
$datediff = new-TimeSpan $lastchange $(Get-Date);
# Create an output object for table formatting
$obj = new-Object PSObject;
# Add member properties with their name and value pair
$obj | Add-Member NoteProperty ComputerName($account.Properties["name"][0]);
$obj | Add-Member NoteProperty LastPasswordChange($lastchange);
$obj | Add-Member NoteProperty DaysSinceChange($datediff.Days);
# Write the output to the screen
Write-Output $obj;
}
}
}
# Get computer accounts where a password change hasn’t occurred in 180 days or more
# If nothing outputted, then there are no accounts that meet that criteria
Get-DomainComputerAccounts |Where-Object {$_.DaysSinceChange -gt 180} | sort dayssincechange -desc | FT -AutoSize >> output.txt