Windows Data Server

[Kelvin Cheung]

My data server runs on Windows Server 2008 R2, lately this issue comes many times, the Internet access icon show No Internet connection, the SSID is shown instead of the AD group name in each access right list in the tab of Security of shared folder, but users (both in Windows and Mac) cannot access the shared folders. After reboot the data server, it works normally.


Do you have any idea the cause of this issue? How to fix it?

 

[WindowsForum AI]

It sounds like you're experiencing a frustrating connectivity issue with your Windows Server 2008 R2 data server, particularly related to networking and shared folder access. Let’s break down the potential causes and solutions for the symptoms you described.

Possible Causes:​

1. Network Connectivity Issues:
   • The "No Internet connection" icon suggests a potential networking problem. This could be due to a misconfigured network adapter, faulty cable, or issues with the router/switch.
2. Active Directory (AD) Problems:
   • The display of the SSID instead of the AD group name in the security settings could indicate a problem with how the server communicates with the Active Directory. This might point to a DNS resolution issue or network configuration problem.
3. Network Discovery and File Sharing Settings:
   • Ensure that Network Discovery and File Sharing are enabled on your server. This is essential for users to access shared folders.
4. Firewall or Security Software:
   • Check if the Windows Firewall or any third-party security software is blocking access to the shared folders.
5. Cached Credentials:
   • Sometimes, credential caching can lead to access issues. Clearing these might help.

Steps to Troubleshoot and Fix:​

1. Check Network Connection:
   • Ensure the server is physically connected to the network.
   • Run the ping command to see if you can reach other devices on the network.
2. Verify DNS Resolution:
   • Check if the server can resolve AD domain names. Use nslookup to verify this.
   • Review Active Directory and Group Policies:
     • Make sure the server is correctly joined to the domain and that there are no Group Policy settings conflicting with access rights.
   • Network Discovery:
     • Go to the Control Panel > Network and Sharing Center, and ensure Network Discovery is turned on.
   • Check Shared Folder Permissions:
     • Right-click the shared folder, go to Properties > Sharing > Advanced Sharing, and then Permissions. Verify the permissions are correctly set for the AD groups.
   • Clear Cached Credentials:
     • Open Credential Manager (Control Panel > User Accounts > Credential Manager) and remove any cached credentials for the shared drives.
   • Reboot or Restart Services:
     • If issues persist, rebooting the server can often temporarily resolve network issues, but it's essential to identify the root cause to prevent recurrence.
   • Update Network Drivers:
     • Ensure that your network drivers are up to date. Sometimes, outdated drivers can cause connectivity issues.

Long-term Solutions:​

• Consider upgrading from Windows Server 2008 R2, as it is out of support and may lack patches or fixes for ongoing issues.
• Regularly monitor the server’s event logs (Event Viewer) for any errors related to networking or file sharing that can provide more insight.

If you continue to face issues after these steps, you may want to capture the specific error messages or log entries generated during these connectivity problems. This information could help narrow down the cause significantly.

 

[Kelvin Cheung]

I have checked that there is no network drivers need to be updated. This issues happens around every 24 hours, and the AD groups of the shared folders are correct, the group name will be shown instead of showing SSID of AD groups and the network connection resume normal after reboot the data server. Could you give further advise of this issue?

 

[WindowsForum AI]

The fact that the issue occurs every 24 hours and resolves after a reboot suggests that this may be related to a scheduled process or service that's failing or misbehaving over time. Here are some more targeted areas to investigate, along with potential solutions:

Further Investigation:​

• Scheduled Tasks:
• Check if there are any scheduled tasks running at regular intervals (e.g., every 24 hours) that could be affecting network connectivity or AD services. Look in Task Scheduler for any unusual tasks.
• Event Viewer Logs:
• Open Event Viewer (run eventvwr.msc) and check the System and Application logs around the time the issue occurs. Look for warning or error entries related to networking, authentication, or Active Directory.
• Network Configuration:
• Examine your TCP/IP settings to ensure they are correctly configured, especially if you are using DHCP. A conflict or renewal issue might be causing the disconnection.
• Wireless Network Issues (if applicable):
• If the server is on a wireless connection, check for interference or router settings that might lead to periodic disconnections.
• DNS Server Availability:
• Ensure that your DNS servers are reliable and functioning as expected. An intermittent DNS resolution issue could cause the symptoms you’re experiencing.
• Group Policy Objects (GPOs):
• Audit Group Policy settings that might be impacting connectivity or the behavior of services on the server.

Possible Solutions:​

• Increase Lease Time for DHCP:
• If using DHCP, consider increasing the lease time to prevent frequent renewals, which may be causing the disconnection.
• Restart Network Services:
• Instead of rebooting the entire server, you can try restarting relevant services (like the "Server" and "Workstation" services) to see if this temporarily resolves the connectivity issue.
• Update Windows:
• Although the drivers are updated, ensure that Windows Server 2008 R2 itself is updated with the latest patches and updates, as this may address underlying issues.
• Consider a Network Reset or Reconfiguration:
• If intermittent issues continue, consider resetting the network configuration (with commands like netsh int ip reset and netsh winsock reset), but back up settings first.
• Network Monitoring Tools:
• Use network monitoring tools to track traffic and identify any unusual activity or patterns that coincide with the issue timeframe.
• Power Management Settings:
• In the device manager, check your network adapter’s properties to ensure that power management settings do not allow the device to be turned off to save power.
• Review Third-Party Software:
• If you have any third-party security/firewall software installed, consider temporarily disabling it to see if it resolves the issue, as these programs can sometimes cause conflicts.

Temporary Workaround:​

While you work on identifying a permanent fix, consider scheduling a regular restart of the network services (or the server itself, if feasible) as a temporary workaround to alleviate the symptoms.
By further investigating these areas, you may be able to pinpoint the cause of the recurring issue. If you continue to experience problems after making these adjustments, providing any additional details or specific errors from the Event Viewer could help yield more tailored advice.

 

[Kelvin Cheung]

About the suggested solution #4
4. Consider a Network Reset or Reconfiguration:
- If intermittent issues continue, consider resetting the network configuration (with commands like netsh int ip reset and netsh winsock reset), but back up settings first.

1. what is the pros and cons of this solution?
2. Why have to to this solution?

 

[WindowsForum AI]

Pros and Cons of Network Reset or Reconfiguration​

Pros:​

1. Clears Misconfigurations:
   • A network reset can clear any misconfigurations that may have accumulated over time, potentially solving connection issues related to IP settings, routing tables, or DNS configurations.
2. Resolves Stubborn Issues:
   • If you’re experiencing persistent connectivity or stability problems and other troubleshooting methods have failed, a reset can often be the last resort that resolves these stubborn issues.
3. Refreshes Network Protocols:
   • Resetting network settings can refresh the networking protocols and services, leading to a cleaner and more responsive network environment.
4. Easy to Execute:
   • The commands (netsh int ip reset and netsh winsock reset) are relatively easy to run and can be performed quickly through Command Prompt.

Cons:​

1. Loss of Configuration Settings:
   • Performing a network reset will revert network settings back to their defaults. This means any specific configurations, such as static IP addresses, DNS server settings, and custom network profiles, will be lost and need to be reconfigured.
2. Potential Downtime:
   • The reset can cause temporary downtime, as it may disrupt connectivity until the settings are properly restored. This could be a concern for production environments.
3. Not a Guaranteed Fix:
   • While it can help resolve some issues, there’s no guarantee that a reset will fix the underlying problem. If there’s a deeper networking issue, it might persist even after a reset.
4. Relearning Curve for Users:
   • If users are accustomed to certain connections or settings, they may have to relearn or adapt to new configurations post-reset, especially in multi-user environments.

Why Perform a Network Reset?​

A network reset or reconfiguration may be warranted for several reasons:

1. Cumulative Network Problems: Over time, as network settings change—perhaps due to software installations, updates, or user modifications—issues can compound and lead to unstable connections or intermittent access issues.
2. Unknown Configuration Issues: Sometimes issues arise from unknown changes in settings, particularly if the environment has undergone various manual adjustments. A reset can offer a fresh start.
3. Troubleshooting Step After Other Solutions Fail: If you've already attempted other troubleshooting methods (like restarting services, rebooting the server, checking logs, etc. and the issue persists, a reset can be a more definitive way to clear the board and start over.
4. Intermittent Connectivity: Given your situation—with connectivity issues occurring every 24 hours—a network reset could help eliminate any underlying configuration anomalies that might be causing these fluctuations.

Before proceeding with a network reset, make sure to document existing configurations and settings so you can restore them if needed. This way, you’re prepared for any necessary adjustments after the reset, reducing any potential downtime or disruption for users accessing shared resources.

 

[Kelvin Cheung]

Why is the network connection become slow, even when I login as administrator, when this issue happen?

 

[WindowsForum AI]

A slow network connection on your Windows Server 2008 R2, even when logged in as an administrator, can be due to several factors. Let's explore some of the common causes and potential solutions:

Possible Causes for Slow Network Connection​

1. Resource Saturation:
   • If the server is under heavy load due to high CPU or RAM usage (e.g., from running applications, services, or multiple user connections), it can lead to slow responses in network access.
2. Network Congestion:
   • If multiple users are accessing the network or specific shared resources simultaneously, it may lead to congestion, slowing down the network for all users, including administrators.
3. Faulty Hardware:
   • Issues with the network adapter, cabling, or switches can result in poor performance. Check for any physical damages or loose connections.
4. Quality of Service (QoS) Settings:
   • If QoS is configured inappropriately, it can prioritize certain types of traffic over others, leading to slowdowns for specific services or users.
5. DNS Resolution Issues:
   • Slow DNS responses can cause delays in accessing network resources, especially if the server struggles to resolve names into IP addresses quickly.
6. Firewall or Security Software:
   • Sometimes, software firewalls or anti-virus programs can throttle network speed due to scanning or filtering traffic, especially if misconfigured.
7. Network Path Issues:
   • Problems in the network path, such as outdated routing tables or an incorrect routing configuration, could lead to slow data transmission.
8. TCP/IP Configuration Issues:
   • Incorrect TCP/IP settings, including duplex mismatches, MTU (Maximum Transmission Unit) settings, or IP address conflicts, can significantly impact performance.

Solutions to Address Slow Network Connection:​

1. Monitor Resource Usage:
   • Use Task Manager or Performance Monitor to check CPU and memory usage during slowdowns. Identify any processes that may be consuming excessive resources.
2. Check for Congestion:
   • If possible, run network monitoring tools to identify bandwidth usage patterns and ascertain if congestion is occurring at peak times.
3. Inspect Hardware:
   • Ensure all cables, network switches, and network interface cards (NICs) are functioning correctly. Replace any faulty hardware as needed.
4. Adjust QoS Settings:
   • If QoS is configured, review and adjust the settings to ensure balanced priority across different types of traffic.
5. Verify DNS Settings:
   • Check your DNS server configurations for any delays. You can use nslookup to diagnose DNS resolution issues.
6. Review Security Software:
   • Temporarily disable or configure firewall or antivirus software to see if it resolves the connection speed issue.
7. Check TCP/IP Settings:
   • Use commands like ipconfig /all to review your network configuration, and consider resetting settings as discussed previously if misconfigurations are suspected.
8. Update Network Drivers:
   • While you mentioned your drivers are up to date, double-check for any specific driver updates from the manufacturer that may address performance issues.
9. Reboot Network Equipment:
   • Sometimes, rebooting the network equipment (routers, switches) can resolve temporary connectivity issues or slowdowns.

By analyzing the conditions surrounding the slow network behavior and employing the above strategies, you should be able to narrow down the cause and restore optimal performance. If slow connections persist despite these efforts, deeper analysis of network topology and settings, or consulting with a network specialist, might be warranted.

 

[Kelvin Cheung]

According to the situation in the previous replies, what is the most possible cause of the slow access and unable to access data server shared folder?

 

[WindowsForum AI]

Given the context and symptoms you've described over the course of our discussion, the most likely causes of both the slow access and inability to access the shared folders on your Windows Server 2008 R2 could be narrowed down to a couple of key factors:

Most Likely Causes:​

1. Active Directory and Network Configuration Issues:
   • Since you mentioned that users cannot access shared folders and the SSID displays instead of the AD group name during connectivity issues, this might indicate that the server is having trouble communicating with the Active Directory. This communication failure can trigger both access problems and slow folder access times as the server may struggle to resolve group permissions correctly.
2. Network Congestion or Saturation:
   • If there are multiple users connecting to the server, especially if they are accessing large files or performing bandwidth-intensive tasks concurrently, the network could become congested. This issue would manifest as slow access for everyone, including administrators.
3. Resource Saturation on the Server:
   • If the server is overloaded with processes or has high CPU or memory usage, it can slow down all network services, including file sharing. This situation might be exacerbated during timeframes when network access issues occur, leading to both slow performance and shared folder access problems.
4. DNS Resolution Problems:
   • If your server frequently struggles to resolve domain names to IP addresses (especially when accessing shared folders based on AD group permissions), this might lead to delays and failures in connecting to resources. This could particularly manifest as slowness when authenticating users against AD or when attempting to access shared folders.
5. Intermittent Network Hardware Issues:
   • Unstable or failing network hardware (routers, switches, NICs) can lead to ongoing connectivity problems, slow access speeds, or intermittent access errors.

Summary:​

The combination of Active Directory communication issues and potential network congestion or hardware problems seems to be the most plausible explanation for the slow access and inability to access shared folders. Specifically, the recurring nature of the disconnections, along with the fact that a reboot temporarily resolves the problems, suggests that addressing the underlying network stability and ensuring proper Active Directory functionality should be prioritized.

Next Steps:​

1. Investigate Active Directory Connectivity: Ensure that DNS settings are correct, and use tools like dcdiag to check the health of domain controllers.
2. Evaluate Network Traffic: Monitor network traffic patterns to see if congestion correlates with access issues.
3. Resource Monitoring: Check the server's performance and resource usage during periods of slow access.
4. Inspect Hardware: Ensure all hardware components are in good condition and functioning effectively.

By focusing on these areas, you should be able to get closer to identifying and resolving the root cause of your server's performance and access issues.

 

[Kelvin Cheung]

I will try to use suggested solution 1 Investigate Active Directory Connectivity: Ensure that DNS settings are correct, and use tools like dcdiag to check the health of domain controllers, firstly.

What is expected outcome to be found if it is related to DNS server? Should I execute the command dcdiag in my domain controller sever? or on the data server?

 

[WindowsForum AI]

Investigating Active Directory connectivity and DNS settings is a crucial step toward identifying the source of your performance and access issues on the Windows Data Server. Here's what to expect and how you should proceed:

Expected Outcomes from DNS Investigation​

1. Correct DNS Resolution:
   • If DNS is working properly, you should be able to perform lookups for your domain and other related services without delays or errors. This means that name resolution for domain controllers, users, and resources should occur quickly.
2. No High Latency in Name Resolution:
   • If you notice high latency when resolving domain names (e.g., using nslookup), this can indicate problems with your DNS servers, possibly contributing to the access delays.
3. Error Messages:
   • Running dcdiag may reveal specific error messages related to DNS or domain controller health, which could shed light on any issues.
4. Domain Controller Health:
   • Using dcdiag, you can assess the overall health of your domain controllers, checking things like replication status and connectivity issues.
5. Troublesome Records:
   • If there are any incorrect or missing DNS records for your domain controllers or any applicable services, this will likely lead to connectivity problems that could manifest as slow access or inability to reach shared folders.

Where to Execute Commands​

• Execution of dcdiag:
  • You should run dcdiag on your domain controller(s) rather than on the data server. This command is specifically designed to diagnose the health of domain controllers and their services. Running it on the domain controller will help identify any issues related to its DNS and overall AD health.
• DNS Commands:
  • On both the domain controller and the data server, you can run commands like nslookup and nslookup to check if name resolution is functioning correctly.

Step-by-Step Procedure​

1. Check DNS Settings:
   • On your data server, ensure that it is configured to use the domain controller(s) as its primary DNS server.
2. Run Diagnostics:
   • Log in to your domain controller.
   • Open Command Prompt with administrative privileges.
   • Execute the command:
     

      dcdiag

   • Review the output for any failures or errors related to DNS and other tests.
3. NSLookup Tests:
   • On both the domain controller and the data server, run:
     

      nslookup

   • Then manually input the domain name or domain controller name to test if the DNS resolution occurs without issue.
4. Analyze Output:
   • Pay close attention to any errors or messages that indicate problems with DNS records, connectivity with other domain controllers, or replication issues.

By executing this procedure and analyzing the outcomes, you'll gain valuable insights into whether DNS issues contribute to the connectivity and performance problems with your data server. If errors are found, addressing those will be your next logical step toward resolving the server issues.

 

[WindowsForum AI]

It seems like you've reposted your previous question. Let me reiterate and clarify the response regarding investigating Active Directory connectivity and the usage of dcdiag.

Expected Outcomes When Checking DNS and Active Directory​

1. Successful DNS Resolution:
   • If DNS is functioning correctly, you should observe quick responses when performing lookups for domain controllers or other domain resources. The commands should return the correct IP addresses without delays.
2. Errors Indicating DNS Problems:
   • If there are issues, you might see errors like "DNS name does not exist," "Server not found," or similar messages during nslookup or when running dcdiag.
3. Domain Controller Health:
   • The execution of dcdiag will assess the overall health of your domain controllers. Key things to look for include:
     • Replication Status: Ensures that domain controllers are replicating correctly.
     • Network Connectivity: Checks if the domain controller can communicate with other DCs and network resources.
     • DNS Tests: Directly tests if the DC can resolve DNS queries correctly.
4. Troubleshooting Output:
   • Look for any errors or "failed" indicators in the output of dcdiag. This can direct your attention to specific issues that need to be fixed.

Where to Execute Commands​

• You should run the dcdiag command on your domain controller(s). This tool is designed to diagnose the health and functionality of domain controllers, making it most effective when executed in that environment.
• On your data server, running nslookup commands can also be beneficial for testing DNS resolution from the server's perspective. You can check if the data server can resolve the domain and the domain controller correctly.

Step-by-Step Action Plan​

1. Verify DNS Settings on the Data Server:
   • Make sure the data server is configured to use the domain controller’s IP addresses as its DNS servers.
2. Run dcdiag:
   • Log into your domain controller.
   • Open Command Prompt as an administrator.
   • Enter the command:
     

      dcdiag

   • Review the output, focusing on any tests that indicate failures.
3. DNS Troubleshooting:
   • Open Command Prompt on both the domain controller and the data server.
   • Run:
     

      nslookup nslookup

     • Confirm correct resolution and response times.

Conclusion​

By following these steps and checking the expected outcomes, you should be able to identify whether DNS issues are contributing to your connectivity and performance problems. If errors arise, addressing them based on the specific messages provided will be key to rectifying any underlying issues within your network.

 

[Kelvin Cheung]

I have run the first test dcdiag on DC controller, where most of tests are passed, except one test is failed: DC1 failed test SystemLog.
And there is an error message displayed in command as following:
The Kerberos Key Distribution Center lacks strong keys for account kerbtgt. An error event occurred. Event ID : 0x40000004

Please provide explanation of this problem and solution to fix it.

 

[WindowsForum AI]

The error message you’re seeing—“The Kerberos Key Distribution Center lacks strong keys for account kerbtgt”—is indicative of a problem with the Kerberos authentication mechanism used by Active Directory. Here's a breakdown of what this means and potential solutions:

Explanation of the Issue​

1. Kerberos Authentication:
   • Kerberos is a network authentication protocol that uses secret-key cryptography to provide secure authentication for users and services in a Windows domain.
2. Kerberos Ticket Granting Ticket (TGT):
   • The kerbtgt account is a special account in Active Directory that represents the Kerberos Ticket Granting Ticket (TGT). It is used to issue tickets for access to various resources within the domain.
3. Error Cause:
   • The error you're facing typically occurs when the kerbtgt account does not have strong keys (encryption algorithms) defined that meet the domain security policy requirements.
   • This may happen if:
     • The domain functional level is set to require stronger encryption but the kerbtgt account is not configured with keys that meet that requirement.
     • There was a problem during a recent key change (often related to password policies or account resets).

Solutions to Fix the Problem​

1. Check and Reset the Kerberos Keys:
   • Resetting the kerbtgt account password will generate new keys:
     • Open a Command Prompt on the domain controller with administrative privileges (run as Administrator).
     • Enter the following command to reset the kerbtgt password:
       

       shell net user kerbtgt /domain

     • You’ll then be prompted to enter a new password. The actual password should be very complex to ensure security.
2. Verify the Domain Functional Level:
   • Check your domain functional level and ensure that it aligns with the encryption standards you wish to use:
     • Open Active Directory Users and Computers.
     • Right-click the domain, select Properties, and check the functional level.
     • If necessary, consider raising the functional level, but ensure all domain controllers and clients are compatible first.
3. Group Policy Settings:
   • Review your Group Policy settings related to Kerberos encryption:
     • Go to Group Policy Management and check the settings under:
       

        Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Kerberos Policy

     • Ensure that the settings here are appropriate for your environment.
4. Event Viewer:
   • Check the Event Viewer logs for any additional events related to Kerberos authentication which might provide more context or indicate other potential issues:
     • Look under:
       

        Applications and Services Logs → Microsoft → Windows → Kerberos → Admin

5. Force a Password Change:
   • If you suspect issues due to a recent password reset or key change, you can force a password change by running this command on the domain controller:
     

     shell ksetup /setcomputerpassword

Conclusion​

By following these steps, you should be able to resolve the issue with the Kerberos Key Distribution Center lacking strong keys for the kerbtgt account. This fix will help restore normal authentication operations in your domain environment and eliminate related errors in the system log.
After applying changes, it may be wise to rerun the dcdiag test to verify that the issue has been resolved successfully.

 

[Kelvin Cheung]

In the properties of our domain, functional level cannot be found.

Instead, when I right-click the domain, there is Raise domain functional level under All task, should I click that option?

 

[WindowsForum AI]

From the images you provided, it looks like you are in the right place to manage the domain functional level for your Active Directory.

Key Observations from the Images:​

1. Domain Properties:
   • The properties window indicates that your domain (UCCKE) currently has its functional level set to Windows Server 2003. This can restrict some of the advanced features available in newer versions of Active Directory.
2. Available Options:
   • The context menu showing the option "Raise domain functional level" suggests that you can upgrade your domain functional level. This step is important for enabling features introduced in later versions of Windows Server.

Should You Click "Raise Domain Functional Level"?​

Yes, you can proceed to click that option to raise the domain functional level, but before you do, consider the following:

Considerations Before Raising the Functional Level:​

1. Compatibility:
   • Ensure that all your domain controllers are running a version of Windows Server that supports the functional level you want to upgrade to. For example, if you upgrade to Windows Server 2008 or later, all your domain controllers must be on at least that version.
2. Backup:
   • It’s good practice to back up your Active Directory and any important data before making changes to the functional level. Although raising the level is usually safe, it’s best to have a fallback.
3. Feature Availability:
   • Be aware that raising the functional level will enable newer Active Directory features (such as advanced security settings, performance improvements, etc. but will disable older functionality available in the previous functional level.

Steps to Raise the Domain Functional Level:​

1. Right-click on the domain in the Active Directory Users and Computers console.
2. Select Raise domain functional level from the context menu.
3. Choose the desired functional level from the dropdown (make sure to read any warnings or notes).
4. Click Raise to confirm the change.
5. Review any messages and close the dialog.

Final Thoughts:​

Raising the domain functional level is a significant step that will enable more modern features and improve security posture, especially if there are known limitations with the current Windows Server 2003 level. If you’re ready and all requirements are met, click the raise option. Afterward, monitor the domain for stability and check the dcdiag results again to ensure that the previous issues are resolved.
If you encounter any problems during or after this process, don’t hesitate to reach out for further assistance!

 

[Kelvin Cheung]

We do have 2 domain controller: named DC1 and DC2 within our domain , both of them run on Windows Server 2012 R2.
Is it okay to for me to click "Raise Domain Functional Level"?
How to backup the Active Directory?

 

[WindowsForum AI]

It's great to hear that both of your domain controllers (DC1 and DC2) are running on Windows Server 2012 R2. This gives you a suitable environment to raise the domain functional level. Here’s what you need to know:

Is It Okay to Click "Raise Domain Functional Level"?​

Yes, you can safely raise the domain functional level given that both of your domain controllers are running Windows Server 2012 R2. This version allows you to take advantage of features introduced in Windows Server 2012 and Windows Server 2012 R2, which enhances your Active Directory capabilities.

Steps to Backup Active Directory​

Backing up Active Directory is crucial for disaster recovery and ensuring that you can restore your environment if needed. Here are the steps to back up your Active Directory:

Method 1: Using Windows Server Backup​

1. Install Windows Server Backup:
   • If it’s not already installed, you can add Windows Server Backup through the Server Manager:
     • Go to Server Manager.
     • Click on Manage > Add Roles and Features.
     • Proceed through the wizard until you reach the Features section.
     • Check the Windows Server Backup option and complete the installation.
2. Open Windows Server Backup:
   • Open Windows Server Backup from the Tools menu in Server Manager.
3. Create a New Backup:
   • Click on Backup Once in the right pane to perform a one-time backup.
   • Choose the backup configuration (full server or custom; for AD, full server is usually best).
   • Select the destination for the backup (local disk, external drive, or network share).
4. Scheduling Backups (Optional):
   • If you want to schedule regular backups, use the Scheduled Backup option instead of Backup Once. Follow the wizard to set your desired schedule and options.
5. Verify the Backup:
   • After the backup completes, verify it by checking the logs in the Windows Server Backup console to confirm that no errors occurred.

Method 2: Using Command Line (Native Method)​

1. Open Command Prompt as Administrator.
2. Run the NTBackup Command:
   • You can use this command:
     

     shell wbadmin start backup -backupTarget:D: -include:C: -quiet

   • Replace D: with your desired backup destination.
   • The -include:C: option backs up the system state, which contains Active Directory.

Important Notes​

• Backup System State: For Active Directory, ensure that your backup includes the System State. This can be done using either Windows Server Backup or a third-party backup solution that supports it.
• Test the Backup: After performing your backup, it may be beneficial to test the restoration process in a non-production environment to ensure it works as expected.

By following these steps, you can ensure that your Active Directory is properly backed up before raising the functional level. Once the backup is complete and confirmed, you can proceed with the Raise Domain Functional Level option with confidence. If you have any further questions or need assistance with the process, feel free to ask!

 

[Kelvin Cheung]

This is the version found about AD in our DC controller.
Is there any problem of this version of AD? Any further suggestion on this issue?