Server 2016 Problems

Summary of Your Issues​

• Initial Login Stuck: Endless spinning dots (update suspected).
• Temporary Improvement: Next login worked, but issues returned post-restart.
• Current Symptoms:
  • "Bad username or password" (despite credentials being correct).
  • No network connection in normal mode, but networking works in Safe Mode.
  • Unable to access Windows Update for troubleshooting.
  • DISM struggles to find a repair source.
  • Suspects: Update issue, Active Directory corruption, or something else.

Diagnostics & Actionable Steps​

1. Networking Issue in Normal Mode​

• Check Device Manager in Safe Mode: Look for any disabled/faulty network adapters.
• Review Event Viewer: Look under System logs for network-related errors during normal boot.
• Clean Boot: Try a clean boot (disable non-Microsoft services/startup items) to rule out third-party cause.

2. "Bad Username or Password"​

• Domain Environment? If it’s a domain controller and you’re logging into a domain account, failure to contact a domain controller (due to networking issues) can kick back invalid login errors.
• Check NLA: Network Location Awareness failure in normal mode can prevent domain logins.

3. DISM Source Issue​

• Correct Image Source: For DISM repair, your install media’s ISO must match your exact OS build and version. Server 2016 has several releases, and DISM is finicky about mismatches.
  • Extract or mount the ISO.
  • Point DISM at the \sources\install.wim (or boot.wim). Command example:
    DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:X:\Sources\install.wim:1 /LimitAccess
  • Replace X: with the drive letter of your mounted ISO.

4. Active Directory Health (if a DC)​

• Run dcdiag in Safe Mode to check for AD corruption.
• Check SYSVOL and NETLOGON shares: Missing or inaccessible = potential AD replication corruption.

5. Other Steps​

• Check Services: Ensure networking and domain-related services (e.g., Netlogon, DNS, DHCP Client) are set to Automatic and running.
• Try SFC: Run sfc /scannow in Safe Mode to check core file integrity.
• Check for Malware: Sometimes, odd update/network/login issues trace back to infection or corruption.

Questions for You​

• Is this server a domain controller or member server?
• Are there replication partners (for AD)?
• Was anything installed/uninstalled before the issues started?
• Do you have available backups or system state snapshots?

1. DISM/Repair Source Fix​

• Use a Server 2016 ISO matching your exact build and edition. Even minor mismatches can cause DISM to fail.
  • Check your installed version with:
    winver
    or
    systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
  • Download the correct ISO if needed.
• Mount the ISO and run:
  DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:X:\sources\install.wim:1 /LimitAccess
  • If “wim:...:1” fails, list available indexes:
    dism /Get-WimInfo /WimFile:X:\sources\install.wim
    and pick the correct one for Server 2016.

2. Network/AD Trouble​

• Since Safe Mode with Networking works:
  • Compare loaded services and drivers between normal and safe mode.
  • Check Device Manager for any misbehaving network adapters in normal boot.
  • In Event Viewer, check under:
  • System → Errors/Warn, esp. for Netlogon, DNS, LSASS, Group Policy, NLA (Network Location Awareness).
• Test (in safe mode, or boot to normal and try):
  
  Code:

  ipconfig /all
  ping 127.0.0.1
  ping <default gateway>
  nslookup <server FQDN>

  • These help identify DNS or IP stack issues.

3. Firewall/Network Profile​

• Windows sometimes mis-classifies the network, leading to AD and firewall blocks (particularly after updates).
  • Run:
    Get-NetConnectionProfile
    Ensure it is “DomainAuthenticated” in normal boot.
  • Try resetting firewall:
    netsh advfirewall reset

4. Last Resort: Restore from Backup​

• If none of the above restore normal operation and you can’t repair the system image or regain stable AD/network, restoring from a recent backup may be safest.
  • Especially as a sole DC, ongoing corruption can risk irreversible AD loss.

5. Prevention: Post-Recovery Considerations​

• For any future Windows updates or major changes, consider snapshots or testing in a clone/VM first.
• If possible, add a second DC VM to guard against single-point AD failures.

What the Error Means​

• DCOM error 1084 with lfsvc commonly appears when Windows is trying to start the Location Framework Service (lfsvc) before certain dependencies are available—often, it’s just informational or a side effect of Safe Mode or network startup order.
• {08D9DFDF-C6F7-404A-A20F-66EEC0A609CD} refers to the CLSID for this geolocation service.
• These errors are not critical for most servers, especially if you don’t use geolocation features. They can safely be ignored unless you’re seeing related service failures.

Why It’s Happening Now​

• This error often pops up:
  • When booting to Safe Mode (services/startup order is altered)
  • After certain Windows Updates
  • If networking or certain Windows services aren’t started in time

What To Check Next​

1. Network/AD Dependency
   • The core problem remains your network stack or a misfiring service that AD relies on.
   • Make sure the following services are set to start automatically (and are running in normal mode):
     • Netlogon
     • DNS Client
     • DHCP Client
     • TCP/IP NetBIOS Helper
     • Workstation/Server
     • Network Location Awareness (NLA)
   • In normal mode, open an administrative command prompt and check network configuration:
     ipconfig /all
     Look for missing IP addresses or DNS settings.
2. Event Viewer
   • Focus especially on errors and warnings for:
     • Netlogon
     • DNS
     • GroupPolicy (Userenv)
     • System components reporting “Failed to start” or “Access denied”
   • Sometimes, a failed service (perhaps networking!) cascades into DCOM/service errors.
3. Network Driver
   • Safe Mode with Networking uses generic drivers. If the network adapter driver in normal mode is corrupt or missing, this blocks authentication (and can explain login/network failures even when Safe Mode works).
   • Check Device Manager in normal mode for any yellow exclamation marks on NICs.
4. Firewall/Domain Profile
   • As previously noted, domain-joined systems use the firewall “Domain” profile; if the system can’t detect the domain network, firewall rules might block authentication.

How To Proceed​

• Don’t worry about the DCOM 1084/lfsvc error itself unless you see cascading service failures listed alongside it.
• Focus on restoring network connectivity and AD services in normal mode:
  1. Use Device Manager to uninstall then reinstall or update the NIC driver.
  2. Reset networking (commands for TCP/IP, Winsock as previously listed).
  3. Ensure all required services (see above) start and are running.
  4. Restart and check again.

• Netlogon - not running in safe mode
• DNS Client - running in safe mode
• DHCP Client - running in safe mode
• TCP/IP NetBIOS Helper - running in safe mode
• Workstation/Server - running in safe mode
• Network Location Awareness (NLA) - running in safe mode

1. Enable Network Troubleshooting Logs in Safe Mode​

• Open a command prompt as Administrator and run:
  
  Code:

  ipconfig /all > C:\network_safe_mode.txt
  netstat -rn >> C:\network_safe_mode.txt
  systeminfo >> C:\network_safe_mode.txt

• You can also export the System and Application event logs:
  
  Code:

  wevtutil epl System C:\SystemLog-SafeMode.evtx
  wevtutil epl Application C:\ApplicationLog-SafeMode.evtx

2. Boot Logging & Recovery Console Use​

• Boot Logging: Enable boot logging at startup (from the F8 advanced boot menu), then inspect C:\Windows\ntbtlog.txt from Safe Mode. This helps identify drivers/services failing to load in normal mode.
• Offline User Management: Use Safe Mode with Networking, or “Directory Services Restore Mode” for more advanced AD repair or password checks.

3. Audit Update History & Pending Updates​

• Check C:\Windows\WindowsUpdate.log
• In Update History (Safe Mode):
  Get-HotFix
• If updates are pending, consider rolling them back or resetting via DISM/SFC as outlined earlier.

4. Check Local User Authentication​

5. Consider a Repair Install or Restore​

Additional Step​

Network Adapter​

• Broadcom NetXtreme Gigabit Ethernet is your physical NIC.
• The interface list shows it as active, and you have an IPv4 address: 10.10.28.1
• Your default gateway is 10.10.28.254

Routing and Connectivity​

• Your route table is configured—that’s a good sign.
• Persistent route/default gateway is in place, suggesting at least basic TCP/IP stack functional in Safe Mode.

What This Tells Us​

• In Safe Mode with Networking, your driver and the basic TCP/IP stack initialize correctly.
• In normal mode, your network doesn’t come up, and you can’t log in—even with what seems like the right credentials.

Theories Based on These Findings​

1. Driver or Service Conflict in Normal Mode
   • In normal mode, a 3rd-party driver/service or security product could be interfering with the NIC initialization or AD authentication process.
   • Safe Mode loads only core Windows drivers, so the issue is likely with something extra loaded in normal mode.
2. Corrupt AD or System Files
   • If AD or security services are unable to start due to corruption or failed updates, this stops normal logon (hence bad creds errors).
3. Stuck/Corrupt Windows Update
   • You mentioned running DISM, but can’t complete /RestoreHealth. An incomplete or failed update could explain system instability.
4. Firewall/Group Policy Issue
   • If group policy or a misapplied firewall rule blocks domain logon, it would prevent DC authentication on boot.

Recommended Next Steps​

1. Check 3rd-Party Software & Drivers​

• In Safe Mode, open msconfig or use Autoruns to see what’s starting on normal boot.
• Disable any non-essential services/drivers (especially antivirus, security tools, VPN, or older NIC software).
• Reboot to normal mode and test.

2. Review Windows Update/Repair​

• In Safe Mode, use:
  sfc /scannow
  This can pick up some file issues without needing a /RestoreHealth source.
• If this finds and fixes errors, try rebooting normal mode.
• Still failing? Try to identify recent update failures via:
  Get-HotFix
  and check logs in C:\Windows\WindowsUpdate.log

3. Try Local Admin Account​

• If you aren’t already, try logging in with the local Administrator account in normal mode, in case the issue is only with domain-based credentials. If that works, it narrows the issue to AD.

4. Network Driver​

• In Safe Mode, uninstall the NIC in Device Manager, tick “Delete the driver software,” and reboot. Let Windows reinstall its default driver.

5. Last Resort: Restore Backup​

• Since this is your only DC, and if all else fails with persistent OS/AD corruption, restoring the latest backup may be your safest bet rather than deep manual AD repair attempts.

• Listing users remotely or locally in Safe Mode means the AD database (NTDS.dit) is accessible and at least somewhat intact.
• However, full AD health depends on replication, DNS resolution, authentication services, and more.
• Since this is a sole DC without replication partners, you cannot verify replication health but can check the integrity of the AD database and service operation.

How to better assess AD health in your situation:​

1. Run dcdiag from Safe Mode with Networking:
   dcdiag /v /c /d /e > C:\dcdiag_report.txt
   This comprehensive check reports on many aspects of DC and AD health.
2. Check Event Viewer for Directory Service errors:
   Look for any critical errors or warnings indicating AD corruption or service failures.
3. Run repadmin to check replication status
   (Less relevant if it's the only DC but useful to verify no local replication issues):
   repadmin /replsummary
4. Verify DNS is properly servicing records for AD domain
   Correct DNS is critical for AD function.

Summary​

What It Confirms​

• AD Database Integrity: If you’re able to enumerate users via PowerShell, it means the AD DS (Active Directory Domain Services) database (NTDS.dit) is accessible and functioning at least at a basic level.
• Domain Controller Functionality: Your domain controller’s key AD service is operational in Safe Mode; this rules out catastrophic corruption of the AD database.
• LDAP/ADWS Availability: The core services that respond to LDAP/ADWS queries are running in Safe Mode.

What It Does Not Confirm​

• Normal Mode Health: It doesn’t guarantee that all AD services and dependencies (like Netlogon, Kerberos, DNS integration) are working correctly in normal mode. Your login/network failure in normal mode usually points to a supporting service, driver, or policy problem, not to AD database corruption.
• Replication Health: Since you mentioned this is a single DC, replication concerns don’t apply. But for multi-DC environments, you’d also need to check AD replication.

Next Steps Given This Info​

• Focus on Services & Drivers: Now that you know AD is intact, your troubleshooting should laser-focus on:
  • Network stack/drivers: Often problematic after Windows Updates.
  • Service startup order and automatic/disabled state: Essential AD-related services may be failing or starting too late in normal mode.
  • Group Policy or Firewall: Sometimes GPO or firewall misconfigs can block authentication.
• Continue to Compare Safe Mode vs. Normal Mode:
  • In Safe Mode, list all running services and drivers and compare with what should be running in normal mode (see earlier advice).
  • Try running msconfig from Safe Mode and do a “Selective Startup” boot, disabling all non-Microsoft services, to isolate third-party interference.
• If Needed: Prepare your backup for restore, but given your AD is accessible, a targeted repair (drivers, services, DISM/SFC, possible repair install) is likely to succeed.

1. Immediate Diagnostics​

A. Check Netlogon Dependencies​

B. Investigate Service-Specific Errors in the Event Log​

C. Check System File and Image Health​

2. Possible Causes​

- Corrupt OS Components or Registry​

• Netlogon might fail if registry/service configuration or binaries are damaged, or if system files are corrupt (pointing to the need for DISM and SFC).

- Driver/Stack Fault​

• If networking layers are still not working in normal mode, that causes Netlogon to fail as well.

- Faulty or disabled dependencies​

• If one of Netlogon’s direct or indirect service dependencies can't start (like TCP/IP stack or Workstation service), Netlogon will not start.

3. Next Steps​

1. Run the above diagnostics for dependencies and event logs.
2. Try SFC and (if possible) the correct DISM /RestoreHealth again from Safe Mode, with your matching Server 2016 installation media.
   If DISM works, attempt to start Netlogon after running it.
3. If you see a specific error in the event log, share it here; that will likely point to the specific file/service/driver at fault.

Note​

• There is no AD database corruption, but critical DC services can’t start, so AD cannot function. This nearly always comes down to system file, service, or dependency corruption.
• If all other repairs fail, a repair install or restore from your backup will get you back in operation fastest—especially since, as a sole DC, lingering failures can risk future instability.

• Corrupted/broken Netlogon executable or supporting OS components
• Blocked network stack or failure in a lower-level driver/service
• A deeper system configuration or registry issue affecting how core services start

Proceed With These Steps:​

1. Check System Event Log for Netlogon Errors​

2. Check If the Netlogon Binary Exists​

3. (Re-)Attempt System File and Image Repair​

• sfc /scannow
• If possible, DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:X:\sources\install.wim:1 /LimitAccess (with a matching Server 2016 image/ISO mounted)

4. Check Network Stack State​

• Can you ping 127.0.0.1, your server’s own IP, or the loopback address?
• Run: ipconfig /all (already done previously—verify the adapter has an IP)
• See if the Workstation service will start:
  Start-Service Workstation

5. If You're Completely Blocked​