Windows – Sync AD DSRM password to a user account

active-directorywindowswindows-server-2012-r2

I can't seem to get the below task scheduler job to work properly in a test domain lab of 2 DCs, 1 win2012 R2 and 1 win2008 R2 DC. Syncing to my 'dsrmuser' user by manually running ntdsutil does work. The Scheduled task runs successfully but doesn't update the password.

http://blogs.technet.com/b/askds/archive/2009/03/11/ds-restore-mode-password-maintenance.aspx

I needed to use a vista level or greater task for the new task to appear in the list of tasks on the win2012 R2 DC. Has anyone used this procedure before? Original post doesn't allow me to comment.

Thanks for any help

Edit:
I tried various versions from the link I posted. Interested in what worked for someone else. I'm using for example:
Run as system.
Windows 7 style task.
Program to run: ntdsutil
Arguments: “SET DSRM PASSWORD” “SYNC FROM DOMAIN ACCOUNT dsrmuser” Q Q

Best Answer

You should have a script with one line of code:

ntdsutil "set dsrm password" "Sync from domain account dsrmuser" quit quit.

The code you provided uses left and right double quotes (“ ”), this is not a good idea. Use ascii double quotes (").

Perhaps it would be due to your aren't specifying the full path to ntdsutil.exe or the Start In location. Also, using a scheduled task is probably overkill. Using a shutdown script would be acceptable after you confirm the code is working as expected.

Related Solutions

Windows Domain – Time Not Propagating to Machines

Try this on the PDC hosting the correct time

NET TIME /SETSNTP:time.windows.com 
NET STOP W32TIME
NET START W32TIME
W32TM /config /reliable:YES
W32TM /resync /rediscover

then on each of the "client" NTP machines

W32TM /resync /rediscover

Impact of increasing the MaxTokenSize for Kerberos Tickets

Many organizations set this to 65535 long ago. There are plenty of Microsoft kb articles that recommend this. Previously the recommendation was 100,000 until Microsoft realized that value did not work, and they corrected this to 65535.

If you use integrated Windows authentication with IIS web sites (such as SharePoint), large tokens can result in failed authentication. This is easily resolved by increasing the value for MaxRequestBytes for the http.sys service. This is due to the Kerberos token with groups is included in each http request. There is also an IIS setting that can improve the performance of integrated authentication so that only the first request has to be authenticated.

I would advise reviewing your groups and convert some to distribution groups unless they are absolutely required to be a security group. Even with a max token size of 65535, it's possible for an account to be a member of so many groups that it cannot logon.

Best Answer

Related Solutions

Windows Domain – Time Not Propagating to Machines

Impact of increasing the MaxTokenSize for Kerberos Tickets

Related Topic