Webbo's World another IT geek's corner of the internet…

Recently working on a File/Print server (that was also a backup DC) and began to receieve the following error from client PC's trying to access it -

Login Failure: the target account name is incorrect

Most google posts seem to refer to checking DNS/WINS settings although in this case everything was fine. I could access the shares via \\192.168.xx.xx but not \\servername. Looking in to the error further there were some error logs referencing kerberos issues and the main clue was found after running netdiag. The netdiag report came back with the below error -

[FATAL] Secure channel to domain 'MYDOMAIN' is broken. [ERROR_ACCESS_DENIED]

So if your having a similar issue then it's usually a case of resetting the machine password via the netdom tool. If it's occuring on a workstation you may want to just remove it from the domain and add it back on, however if a server has the issue then this Microsoft article will help -

http://support.microsoft.com/kb/329721 (Description of netdom.exe Syntax and Versions)
http://support.microsoft.com/kb/260575 (How To Use Netdom.exe to Reset Machine Account Passwords / Domain Controller)

Having recently found a Sony laptop that would not copy / sync a users profile during log off I had a hunt round google and found the below from Experts Exchange. Wouldn't have expected this as the cause but carrying out the below solved the problem. One minor note on the particular Sony laptop was that the Sony Event service also needed to be disabled - otherwise the user was spammed with the Vaio Power management feature believing the speed / stamina switch had been changed and the Graphics settings were to be adjusted.

Domain Environment: Microsoft Server 2003/Server 2003 R2 SP2
Affected Operating Systems: Windows XP SP1/SP2/SP3, Vista

Solution:

I have found that the NVIDIA drivers can break roaming profiles functionality. Un-install the video drivers through add/remove programs. Reboot the workstation and see if the profile is written back to the server at logoff.

Re-install NVIDIA drivers & before re-starting the computer:

Go to

1) Start Menu>Run> type services.msc
Scroll down the list of services to: "NVIDIA Display Driver Service" Stop this service from running and also Disable the service from starting again.

2) Go to Start Menu>Run> type msconfig uncheck nwiz.exe, Nvcpl & RunDll32.exe NvMCTray.dll,NvTaskbarInit under startup tab. Then press apply & okay buttons. Do not restart the computer when prompted.

3) Go to Command Prompt:

Start Menu>Run> type cmd press okay
Browse to C:\windows\system32 folder
Cd\ <press enter>
Cd windows\system32 <press enter>
Manually rename the following files after installation and before rebooting:
ren nvcpl.dll nvcpl.dlx <press enter>
ren nvcplui.exe nvcplui.exx <press enter>

4) Reboot Computer & Confirm Profile writes back to server at logoff.

If like me you're trying to install the SQL Service Pack 4 (KB948119) via Microsoft Update and it fails (without any obvious error) then here's a possible fix. I've found one reason may be if the MSSQL$SBSMONITORING service isn't running - at least this was the case for me when it failed on various Windows Small Business Servers.

Fix:
1) Go to Start - Run - type in Services.msc
2) Look for the MSSQL$SBSMONITORING service
3) If this is stopped or disabled then double click the service name to bring the properties window up
4) Within the properties either start the service or set it's startup type to Automatic and then start the service
5) Retry the Microsoft Update

Having set up a Server 2003 Domain Controller in a remote site we found the following error whilst trying to replicate between the two locations, Active Directory and DNS seemed to replicate correctly however the Sysvol folder remained empty, the error is below:

Event ID: 13508
Description:
The File Replication Service is having trouble enabling replication from to for
using the DNS name . FRS will keep retrying.
Following are some of the reasons you would see this warning.

[1] FRS can not correctly resolve the DNS name from this computer.
[2] FRS is not running on .
[3] The topology information in the Active Directory for this replica has not yet replicated to all the Domain Controllers.

This event log message will appear once per connection, After the problem is fixed you will see another event log message indicating that the connection has been established.

Fix:
In our case it was a firewall between the sites blocking the RPC traffic so once this was opened up between the two servers it replicated without any problems. Here's the article we found on Experts Exchange that helped us go through the quick checks:

1) Examine the FRS event ID 13508 to determine the machine that FRS has been unable to communicate with.

2) Determine whether the remote machine is working properly, and verify that FRS is running on it. Type the following command at a command prompt on the computer that logged the FRS event ID 13508 and press ENTER:

ntfrsutl version

If this fails, check network connectivity by using the Ping command to ping the fully qualified domain name (FQDN) of the remote domain controller from the computer that logged the FRS event ID 13508. If this fails, then troubleshoot as a DNS or TCP/IP issue. If it succeeds, confirm that the FRS service is started on the remote domain controller.

3) Determine whether FRS has ever been able to communicate with the remote computer by looking for FRS event ID 13509 in the event log and see if the FRS problem correlates to recent change management to networking, firewalls, DNS configuration, or Active Directory infrastructure.

4) Determine whether anything between the two machines is capable of blocking RPC traffic, such as a firewall or router.

5) Confirm that Active Directory replication is working. For more information about troubleshooting Active Directory replication, see Troubleshooting Active Directory Replication Problems in this guide.

Having gone through several articles we also found alot of users fixed this via a registry tweak. It's a D2 tweak on the 'secondary' server telling it to pull replication from the Primary DC and a D4 registry tweak on the 'primary' server telling it that it holds all of the master records to replicate out.

D2 - Non-Authoritative restore (pull from another DC)
D4 - Authoritative restore

Steps for setting D2/D4 are:

1) Stop File Replication service via Start - Run - type in CMD, click ok. In the Command Prompt window type 'net stop ntfrs' and press enter

2) Use RegEdit to edit "BurFlags" in the key "HKLM\System\CurrentControlSet\Services\Ntfrs\Parameters\Backup/Restore\Process at Startup"
* edit the dword key "BurFlags" in Hex format.
* change from 0 to D2 or D4

3) Start the File Replication service via Start - Run - type in CMD, click ok. In the Command Prompt window type 'net start ntfrs' and press enter

Having demoted a Windows 2003 Domain Controller and re-promoting into a different domain DNS began throwing the following error referencing the old domain name, which no longer existed:

Event ID: 4007
Source: DNS
Description: The DNS server was unable to open zone <zone> in the Active Directory from the application directory partition <partition name>. This DNS server is configured to obtain and use information from the directory for this zone and is unable to load the zone without it. Check that the Active Directory is functioning properly and reload the zone. The event data is the error code.

Fix:
1) Open Regedit via Start - Run - type Regedit and click ok
2) Browse to HKLM\System\ControlSet\Services\DNS\Zones
(This may have been moved to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\Zones)
3) Export and then delete the zones that are no longer needed

Checking zone information with ADSIEdit.msc may also be required however removing the above seems to have worked to us. In ADSI check - DC=DomainDNSZones,DC=(yourdomain),DC=local partition