Provision FS01 File Server Foundation

Build a domain-joined Windows file server with secure SMB and an F: volume.

Introduction

30 Second Summary

Shared company files need a dependable home. Mixing them into a machine that already handles logins or databases makes every change riskier.

In this project, you will provision a dedicated Windows Server 2022 virtual machine named FS01 for cloudseam.tech. The finished server provides an isolated foundation for secure departmental file services.

What You'll Build

Signing in to FS01 reveals a healthy domain member that is ready to host future departmental shares.

By the end of this project, you'll have:

A dedicated file-server baseline that reports the File Server role as installed while requiring inbound SMB signing.
A successful Active Directory DNS lookup that returns the domain controllers responsible for cloudseam.tech.
A separate data volume where you can open F: to see a clean NTFS volume labeled Data.
Secret Mission: Add FS01 to Server Manager on a domain controller to inspect its role and storage inventory remotely.

Are there any prerequisites?

VMware Workstation Pro with the existing Windows Server 2022 evaluation ISO provides the local installation environment.

A healthy cloudseam.tech lab provides two domain controllers, their IPv4 addresses, an unused static address, and authorized domain join credentials.

Before We Start

This first checkpoint locks in your plan to build FS01 as a dedicated Windows Server 2022 member server for cloudseam.tech. It also connects that choice to the reason your domain controllers and SQL Server should remain focused on their existing workloads.

Build the Dedicated FS01 Virtual Machine

File services are safer when they have their own failure boundary. A dedicated Windows Server 2022 virtual machine keeps file-service experiments away from either domain controller or SQL Server.

VMware Workstation Pro provides that isolated boundary. In this step, you size FS01 for the lab before installing Desktop Experience.

In this step, get ready to:

Create the FS01 VM on the same VMware virtual network as the domain controllers.
Install Windows Server 2022 Desktop Experience on a persistent 60 GB operating-system disk.
Confirm the graphical server baseline from a local Administrator session.

Create the virtual machine

VM sizing prevents the new server from competing unnecessarily with the rest of your lab. The shared VMware network lets FS01 reach the domain controllers in later steps.

Press Cmd+Space on macOS or the Windows key on Windows to open system search.
Type VMware Workstation Pro into the search field.
Press Enter to open VMware Workstation Pro.
Select File in the top menu.
Select New Virtual Machine.
Choose Typical when the wizard asks for a configuration type.
Select Use an ISO image as the installation source.
Browse to the existing Windows Server 2022 evaluation ISO.

What Is the ISO Doing?

The ISO acts as the installation media inside the VM. VMware attaches it to a virtual optical drive so FS01 can start the Windows Server installer.

Continue until the wizard asks for the virtual machine name.
Enter FS01 as the virtual machine name.
Continue until the wizard asks for the operating-system disk capacity.
Set the disk capacity to 60 GB.
Leave Independent disk mode disabled.
Select Customize Hardware.

The hardware window controls how much of the host computer FS01 can use. It also controls which virtual network the server joins.

Set the VM memory allocation to 4 GB.
Set the total virtual processor count to 2.
Select the network adapter entry in the hardware list.
Choose the same VMware virtual network used by both domain controllers.
Configure the network adapter to connect when FS01 starts.
Close the hardware window.
Select Finish to create the VM.

You should see FS01 in the VMware library. Its hardware summary should show 2 virtual CPUs, 4 GB of memory, and one 60 GB operating-system disk.

VM Creation Did Not Complete?

Confirm that the ISO path points to the existing Windows Server evaluation media.
Confirm that another VM does not already use the name FS01.
Match the network adapter to the VMware network used by both domain controllers.

Ask for targeted help with troubleshooting the FS01 VM creation.

Install the graphical server edition

Desktop Experience installs the standard Windows graphical interface. It also includes Server Manager for local administration.

This part can take several minutes while the installer copies operating-system files. Several automatic restarts are normal.

Select FS01 in the VMware library.
Start the VM with the VMware power control.
Boot the VM from the attached evaluation ISO.
Select a Windows Server 2022 evaluation edition whose name includes Desktop Experience.
Accept the license terms.
Select Custom: Install Microsoft Server Operating System only (advanced) as the installation type.
Select the empty 60 GB disk as the installation target.
Start the installation.

The installer copies Windows Server to the virtual disk. The VM restarts automatically when this phase finishes.

The local Administrator password is the only credential created here. It gives you access before domain membership exists.

Enter a strong password for the local Administrator account.
Enter the same password in the confirmation field.
Store the password in a secure password manager.
Complete the password prompt.
Sign in locally as Administrator.

That is the operating-system milestone complete. You should see the full Windows graphical desktop instead of a command-only server interface.

Desktop Experience Did Not Load?

Confirm that the installed edition name included Desktop Experience.
Let the VM boot from its virtual disk after the installer restarts it.
Reinstall the operating system if you selected a Server Core edition.

Ask for help with diagnosing the missing Windows desktop.

Confirm the visible server baseline

The visible desktop proves that the graphical server edition is active. VMware hardware settings confirm that the guest has the intended lab boundary.

Switch back to VMware Workstation Pro without shutting down FS01.
Select FS01 in the VMware library.
Select VM in the top menu.
Select Settings.
Select the Hardware tab.
Confirm that the memory value is 4 GB.
Confirm that the virtual processor count is 2.
Confirm that the operating-system disk capacity is 60 GB.

Those values confirm that the VM matches the planned lab size. The disk should remain in persistent mode.

Select the network adapter entry.
Confirm that the adapter is connected.
Confirm that its VMware virtual network matches both domain controllers.
Close the settings window without changing the verified values.

The adapter should report a connected state. Its network selection should match the network used by the two cloudseam.tech domain controllers.

Network Baseline Does Not Match?

Set the network adapter to the same VMware virtual network as both domain controllers.
Enable the adapter connection for the running VM.
Confirm that the VM is powered on before checking the connected state.

Ask for help with matching the FS01 network adapter.

Before the final baseline check, what do you expect to appear after the local Administrator signs in?

Return to the FS01 console.
Sign in as the local Administrator if the session is locked.
Wait for the Windows desktop to finish loading.
Select Local Server in Server Manager.

You should see the full Windows graphical desktop. Server Manager should load its Local Server page with Windows Server 2022.

The server should still show a workgroup state. This confirms that FS01 has not joined cloudseam.tech early.

Server Manager Did Not Open?

Press the Windows key to open Windows search.
Type Server Manager into the search field.
Press Enter to open Server Manager.
Recheck the installed edition if the Windows graphical desktop is also missing.

Ask for help with opening Server Manager on FS01.

Your dedicated file-server boundary is now running with the required graphical baseline. Next, you will test what happens when Active Directory discovery uses the wrong DNS source.

Break Active Directory Discovery on Purpose

Your dedicated FS01 virtual machine is running on the same lab network as both domain controllers. The next risk stays hidden until the server tries to find cloudseam.tech.

A domain join depends on Active Directory DNS discovery. This controlled failure shows what happens when FS01 consults the wrong DNS phone book.

In this step, get ready to:

Point FS01's Preferred DNS server to 127.0.0.1 while preserving its existing IPv4 address configuration.
Query the domain-controller locator record from Command Prompt.
Explain why the locator query fails.

Point DNS at the wrong place

The current IPv4 address configuration stays in place. Only the DNS server destination changes.

Changing network settings can feel risky. You are preserving the existing IP address fields throughout this edit.

Switch back to Server Manager from the previous step.
Select Local Server in the left sidebar.
Select the Ethernet link beside the connected network adapter.
Right-click the connected Ethernet adapter.
Select Properties.
Select Internet Protocol Version 4.
Select Properties.
Leave the current IPv4 address configuration unchanged.

Choose the manual DNS server option.
Enter 127.0.0.1 in the Preferred DNS server field.
Remove any value from the Alternate DNS server field.

The DNS section should now show 127.0.0.1 as the preferred server. The alternate server field should be empty.

Apply the IPv4 changes by selecting OK.
Close the Ethernet properties window.
Return to the Internet Protocol Version 4 properties.
Confirm that Preferred DNS server shows 127.0.0.1.
Confirm that Alternate DNS server remains blank.

The careful part is done: FS01 now lists 127.0.0.1 as its only DNS server.

Query the domain-controller locator record

Active Directory publishes SRV resource records that identify domain controllers. The LDAP locator query asks DNS which servers provide logon services for cloudseam.tech.

Press the Windows key to open Windows search.
Type Command Prompt.
Press Enter to open Command Prompt.

Before you query the record, make a quick prediction about whether FS01 can find a domain controller through its configured DNS server.

Submit the locator query by entering each line below separately:

nslookup
set type=all
_ldap._tcp.dc._msdcs.cloudseam.tech

What Do These Commands Do?

The nslookup command starts the interactive DNS lookup tool.
The set type=all entry requests every available record type.
The _ldap._tcp.dc._msdcs.cloudseam.tech entry asks for the domain-controller locator records.

The lookup fails to return any SRV service location records for cloudseam.tech.

You have now reproduced the discovery problem that a domain join would face with this DNS configuration.

Did the Lookup Return Records?

Return to the Ethernet IPv4 properties.
Confirm that Preferred DNS server contains 127.0.0.1.
Confirm that Alternate DNS server is blank.
Repeat the three-line query shown above.

Ask for targeted help with diagnosing an unexpected successful SRV lookup.

Explain the controlled failure

DNS is a school phone book. Active Directory adds special entries that identify the offices providing logon services.

FS01 looked in its own empty phone book. It could not find either domain controller.

Why Did Discovery Fail?

The address 127.0.0.1 sends the DNS request back to FS01 through its loopback interface. FS01 has no DNS zone containing the locator records for cloudseam.tech.

The empty alternate DNS field leaves the server without another DNS source. The failed SRV lookup proves that sharing a network with domain controllers does not provide domain discovery by itself.

Keep the failed query visible in Command Prompt.
Use the explanation above to diagnose why FS01 found no locator record.

FS01 has proved that a server can share a network with its domain controllers yet still fail discovery when DNS points to the wrong place. Next, you will replace this controlled failure with a stable network identity that can locate cloudseam.tech.

Give FS01 a Stable Network Identity

The failed lookup proved that DNS controls how FS01 discovers the domain controllers for cloudseam.tech. Pointing the server at its own empty DNS service broke that discovery path.

A static IPv4 configuration gives the future file server a predictable address. Using both domain controllers for DNS restores the Active Directory records that FS01 needs for its later domain join.

In this step, get ready to:

Capture the working subnet information.
Assign the planned static IPv4 configuration.
Prove that domain-controller discovery works through DNS.

Capture the working subnet information

The current network report gives you a baseline for the static configuration. The new address must remain on the working lab subnet.

Switch back to Command Prompt from the previous step.
Display the complete network configuration by running this command:

ipconfig /all

What Does This Report Show?

The report identifies the Ethernet adapter carrying FS01's lab traffic. It also shows the addressing values that keep the adapter on the lab subnet.

The DNS server entry still shows 127.0.0.1. This confirms that you are inspecting the configuration responsible for the failed lookup.

You should see an Ethernet adapter with an IPv4 address on the same lab subnet as the domain controllers.

Record the adapter name: your Ethernet adapter name.
Record the current IPv4 address: your current IPv4 address.
Record the subnet mask: your subnet mask.
Record the default gateway: your default gateway.
Record the DHCP-provided DNS details from your lab network records: your DHCP-provided DNS details.

The planned address must be unused before FS01 claims it. Your lab IP address plan provides the source of truth for this check.

Record the planned FS01 address: your planned static IPv4 address.
Check the planned address in your lab IP address plan.
Confirm that no device is assigned to the planned address.
Record the first domain controller address from your prerequisite notes: your first domain controller IPv4 address.
Record the second domain controller address from your prerequisite notes: your second domain controller IPv4 address.

Why Use Both Domain Controllers?

Each domain controller provides the DNS records that identify Active Directory services. Two DNS server addresses preserve discovery when one domain controller is unavailable.

Configure IPv4 through the graphical interface

Changing the active adapter can briefly interrupt FS01's connection. Your recorded baseline gives you exact values to restore if a field is entered incorrectly.

Return to the Ethernet adapter's Internet Protocol Version 4 properties from earlier.
Select Use the following IP address.
Enter your planned static IPv4 address in the IP address field.

The IP address field now shows the unused address reserved for FS01.

Enter your subnet mask in the Subnet mask field.
Enter your default gateway in the Default gateway field.

The subnet mask keeps FS01 in the correct local address range. The default gateway provides its route beyond that range.

Enter your first domain controller IPv4 address in the Preferred DNS server field.
Enter your second domain controller IPv4 address in the Alternate DNS server field.

Both DNS fields now point to domain controllers instead of the local loopback address.

Apply the Internet Protocol Version 4 settings.
Close the Ethernet properties window.

The adapter may reconnect briefly. FS01 should remain attached to the same lab network.

Lost Network Connectivity?

Return to the Internet Protocol Version 4 properties. Compare the subnet mask with the value you recorded.

Compare the default gateway with the recorded value. Restore the previous IPv4 configuration if the planned address belongs to a different subnet.

Ask for targeted help with diagnosing the static IPv4 configuration.

Prove that Active Directory DNS works

The first check confirms that Windows accepted the static values. The final lookup tests whether the new DNS servers can locate the domain controllers.

Switch back to Command Prompt.
Display the updated network configuration by running this command:

ipconfig /all

What Does This Check Confirm?

The report should show a static address for the Ethernet adapter. Its DNS entries should identify both domain controllers.

The IPv4 address should match your planned static IPv4 address.

The subnet mask should match your subnet mask. The default gateway should match your default gateway.

The DNS server entries should show your first domain controller IPv4 address followed by your second domain controller IPv4 address.

Static Values Do Not Match?

Return to the Internet Protocol Version 4 properties. Correct the value that differs from your recorded network plan.

Run the network report again after applying the correction.

Ask for help with comparing the saved IPv4 settings.

Before you repeat the lookup, do you expect FS01 to find the domain controllers through its new DNS configuration?

Repeat the domain-controller locator query by entering these lines in order:

nslookup
set type=all
_ldap._tcp.dc._msdcs.cloudseam.tech

What Does This Lookup Prove?

The query requests the LDAP SRV records used to locate domain controllers. A successful response proves that FS01 can discover Active Directory services for cloudseam.tech.

Both domain controllers now provide authoritative DNS information for that discovery process.

You should see one or more SRV service location records. Their server names should belong to the cloudseam.tech domain.

That closes the discovery gap. FS01 now has a stable IPv4 address plus two working DNS paths to the domain controllers.

The Lookup Still Fails?

Check that the first domain controller address is the preferred DNS server. Check that the second domain controller address is the alternate DNS server.

Confirm that FS01 remains connected to the same virtual network as both domain controllers. Repeat the lookup after correcting any mismatched value.

Ask for focused help with diagnosing the failed SRV lookup.

FS01 can now find the domain services it needs. Next, you will give file data its own NTFS volume instead of placing it on the operating-system disk.

Prepare a Separate Data Volume

FS01 can now find both domain controllers through Active Directory DNS. Its future department files still share the 60 GB operating-system disk with Windows.

A separate data volume gives those files their own storage boundary. Future recovery work starts from a cleaner layout.

VMware Workstation Pro will provide the new disk. Windows Server 2022 will prepare that disk for later file-sharing projects.

In this step, get ready to:

Add a persistent 40 GB virtual hard disk to FS01.
Initialize the new disk as GPT in Disk Management.
Create an empty NTFS volume using drive letter F: and volume label Data.

Add the 40 GB data disk

A virtual hard disk gives the virtual machine additional storage without changing its operating-system disk. Persistent storage keeps future department data available across shutdowns.

Shut down the FS01 guest from Windows.

The VMware console should show that FS01 is powered off.

Switch back to VMware Workstation Pro from earlier.
Select FS01 in the virtual machine list.
Open the VM menu.
Select Settings.

The settings window should list the existing 60 GB operating-system disk.

Select the Hardware tab.
Start the New Hardware wizard.

The wizard should display the hardware devices that VMware can attach to FS01.

Select Hard Disk.
Select Create a new virtual disk.

The wizard should now ask how VMware stores the new virtual disk.

Keep the default virtual-disk type.
Set the disk capacity to 40 GB.

The disk summary should show the new 40 GB capacity.

Leave Independent unselected.
Select Finish.

The hardware list should now show a second virtual hard disk with 40 GB of capacity.

Why Keep the Disk Persistent?

A persistent disk keeps file changes after FS01 powers off. Nonpersistent mode discards changes when the virtual machine powers off or resets.

Leaving Independent unselected also keeps the data disk aligned with the snapshot workflow used later in the lab.

Start FS01 in VMware Workstation Pro.
Sign in locally with the Administrator account.

The Windows desktop should load with the second disk attached to FS01.

New Disk Was Not Added?

Confirm that FS01 was powered off before you changed its virtual hardware.
Return to the Hardware tab to confirm that a second 40 GB hard disk is listed.

Ask for targeted help with adding the VMware data disk.

Initialize the new disk as GPT

Disk Management must initialize a blank disk before Windows can create a volume on it. GPT supplies the partition structure for the new disk.

Choose Only the Blank Disk

Disk selection is the fiddly part here. Initializing a disk already in use erases its data.

The new disk has 40 GB of capacity with Unallocated space. Keep the 60 GB operating-system disk untouched.

Press the Windows key to open Windows search.
Type Disk Management.
Open Disk Management with administrator access.
Approve the administrator request if Windows displays one.

Disk Management should list the existing operating-system disk plus a new disk with approximately 40 GB of capacity.

Locate the new disk by its 40 GB size.
Confirm that its capacity is marked Unallocated.
Bring the new disk Online if Disk Management shows it as offline.

The new disk should now be online with all of its capacity still unallocated.

Right-click the identifier area for the new blank 40 GB disk.
Select Initialize Disk.

The initialization dialog should identify the same blank disk you selected.

Select only the new blank 40 GB disk.
Choose GPT as the partition style.
Confirm the initialization.

Disk Management should show the new disk as Online. Its full capacity should remain Unallocated.

Unsure Which Disk to Initialize?

Compare the displayed capacities before selecting a disk.
Keep the 60 GB operating-system disk unchanged.
Select only the blank disk with approximately 40 GB of unallocated capacity.

Ask for help with identifying the correct disk.

Create the F: data volume

A simple volume turns the unallocated capacity into storage that Windows can use. The finished volume uses the full disk with drive letter F:.

Right-click the Unallocated space on the new 40 GB disk.
Select New Simple Volume.

The New Simple Volume wizard should open for the selected disk space.

Use the full available capacity for the volume.
Assign drive letter F:.

The wizard should now show F: as the drive letter for the new volume.

Select NTFS as the file system.
Enter Data as the volume label.

The format summary should identify an NTFS volume labeled Data.

Complete the New Simple Volume wizard.

You have the storage foundation sorted. Disk Management should show Data (F:) as an Online and Healthy NTFS volume.

Before you inspect the finished volume, do you expect to find any files inside it?

Return to Disk Management from earlier.
Confirm that the 40 GB disk reports Online.
Confirm that the Data volume reports Healthy.
Press the Windows key to open Windows search.
Type File Explorer.
Press Enter to open File Explorer.
Select F: in the navigation pane.

You should see an empty volume named Data with approximately 40 GB of capacity. Disk Management confirms that the volume uses NTFS and remains healthy.

Volume Details Do Not Match?

Return to Disk Management to confirm that the volume occupies the full 40 GB disk.
Confirm that the assigned drive letter is F:.
Confirm that the volume label is Data.

Ask for targeted help with checking the finished data volume.

FS01 now has a clean F: data volume beside its operating-system disk. Next, you will give the server its permanent identity before joining it to the domain.

Join the Domain and Establish the File-Server Baseline

Your separate F: data volume is ready. Active Directory DNS can now locate the domain controllers.

FS01 still trusts only its local account database. Domain membership gives the server a secure channel with cloudseam.tech.

You will install only the File Server role needed by later projects. You will also require inbound SMB signing.

In this step, get ready to:

Set the permanent computer name to FS01.
Establish trusted membership in cloudseam.tech with a healthy secure channel.
Install the File Server role with inbound SMB signing required.

Give the server its permanent name

A permanent computer name gives the server one consistent identity across DNS records and management tools. The name FS01 identifies its file-server purpose.

Return to Server Manager from earlier.
Select Local Server in the left navigation pane.
Select the current Computer name link.
Change the computer name to FS01.
Apply the name change.

The restart ends your current session. Your local Administrator account remains the correct sign-in for this restart.

Restart FS01 when Windows prompts you.
Sign back in with the local Administrator account.
Return to Local Server in Server Manager.
Confirm that Computer name now shows FS01.

The permanent name is in place. Server Manager now identifies this machine as FS01.

Computer Name Still Unchanged?

Return to the Computer name link on Local Server.
Confirm that the new name contains exactly FS01.
Restart the server again if Windows still reports a pending name change.

Ask for help with diagnosing the computer-name change.

Join cloudseam.tech

A domain join creates the FS01 computer account in cloudseam.tech. It also establishes the trust relationship used for domain authentication.

Return to Server Manager from earlier.
Select Local Server in the left navigation pane.
Select the Workgroup link.
Select Change on the Computer Name tab.
Choose Domain under Member of.
Enter cloudseam.tech as the domain.
Submit the domain change.

The credential prompt authorizes a computer-account change in your lab domain. Use only the domain administrative account set aside for this lab.

Provide the authorized domain credentials when Windows asks.
Restart FS01 after Windows accepts the domain join.
Sign in with the domain administrative account.

FS01 now belongs to cloudseam.tech. A secure-channel test confirms that the membership is active.

Press the Windows key to open Windows search.
Type Windows PowerShell into the search field.
Open Windows PowerShell with administrator access.

Before you run the check, do you expect the newly joined server to report a healthy domain relationship?

Test the domain secure channel by running this command:

Test-ComputerSecureChannel -Verbose

What Does This Command Do?

The command tests the trust relationship between FS01 and cloudseam.tech.
The verbose output exposes the result of the secure-channel check.
A result of True confirms that the channel is healthy.

The trust boundary is now working. You should see True from the secure-channel test.

Secure Channel Check Did Not Succeed?

Confirm that the Ethernet adapter still uses both domain-controller IPv4 addresses for DNS.
Repeat the Active Directory DNS discovery test from the previous step.
Confirm that you signed in with the authorized domain administrative account.

Ask for help with diagnosing the domain secure channel.

Establish the file-server baseline

The File Server role adds the Windows role service needed to host file shares. Selecting only this role keeps the server focused on file services.

Return to Server Manager from earlier.
Select Manage in the top menu.
Select Add Roles and Features.
Choose Role-based or feature-based installation.
Select FS01 as the destination server.
Expand File and Storage Services.
Expand File and iSCSI Services.
Select File Server.

Why Install Only the File Server Role?

The role provides the file-sharing service needed by future projects. Keeping the role selection narrow preserves FS01 as a dedicated file server.

Complete the role installation.

Server Manager should report that the File Server role installed successfully. FS01 now has the role service required for later departmental shares.

Role Installation Did Not Complete?

Return to the Server Manager wizard.
Confirm that File Server remains selected under File and iSCSI Services.
Complete any pending Windows restart before retrying the installation.

Ask for help with troubleshooting the File Server role installation.

SMB signing acts like a tamper-evident seal on every envelope. The recipient can detect a message changed in transit.

The Local Security Policy settings control the SMB server requirement on FS01. Local Group Policy Editor exposes that policy under Computer Configuration.

Press the Windows key to open Windows search.
Type gpedit.msc into Windows search.
Press Enter to open Local Group Policy Editor.
Expand Computer Configuration.
Expand Windows Settings.
Expand Security Settings.
Expand Local Policies.
Select Security Options.

The right pane now lists the local security policies for FS01. The SMB server policy controls whether clients must use signed traffic.

Open Microsoft network server: Digitally sign communications (always).
Enable the policy.
Apply the policy change.
Restart FS01.
Sign back in with the domain administrative account.

The restart applies the local signing requirement. The final checks now test trust and role state plus SMB protection.

Press the Windows key to open Windows search.
Type Windows PowerShell into the search field.
Open Windows PowerShell with administrator access.

Before you run the final check, do you expect all three results to confirm the completed baseline?

Verify the domain channel and File Server role plus SMB signing by running these commands:

Test-ComputerSecureChannel -Verbose
Get-WindowsFeature -Name FS-FileServer
Get-SmbServerConfiguration | FL RequireSecuritySignature

What Do These Checks Prove?

Test-ComputerSecureChannel -Verbose verifies that FS01 still has a healthy relationship with its domain.
Get-WindowsFeature -Name FS-FileServer reports whether the File Server role is installed.
Get-SmbServerConfiguration | FL RequireSecuritySignature displays the inbound SMB signing requirement.

The secure-channel command should return True.

The File Server role should appear in the Installed state.

The SMB configuration should show RequireSecuritySignature : True.

That finishes the foundation. FS01 is ready for later file-sharing projects.

One of the Final Checks Did Not Match?

Confirm that the Ethernet adapter still uses both domain-controller IPv4 addresses for DNS if the secure-channel check does not succeed.
Repeat the File Server role installation if the role check does not show Installed.
Reopen the SMB server policy if the signing check does not show the required state.

Ask for help with diagnosing the incomplete FS01 baseline.

Secret mission

Manage FS01 Remotely from a Domain Controller

Enable remote management on FS01. Add it to a domain controller's Server Manager pool. Inspect its role and storage inventory without opening the FS01 console.

Clean Up Your Resources

The lab creates no metered cloud resources, so FS01 adds no incremental service charges. Its persistent virtual disks still consume storage on your Mac.

Resources you used:

A persistent FS01 virtual machine registered in VMware Workstation Pro.
One persistent 60 GB operating-system virtual disk attached to FS01.
One persistent 40 GB data disk containing the empty NTFS volume F: labeled Data.
An FS01 computer account in Active Directory for cloudseam.tech.
An FS01 entry in the domain controller's Server Manager server pool.
The File Server role installed on FS01.
A local requirement for inbound SMB signing.

Keep everything running

No action is needed. Choose this if you plan to build departmental shares on this server in the next project.

Keep FS01 registered in VMware Workstation Pro.
Keep FS01 joined to cloudseam.tech.
Keep the empty F: volume available for future departmental folders.
Keep FS01 in the domain controller's Server Manager server pool.
Plan the remaining series labs within the evaluation's 180-day window.

FS01 remains ready for later sharing work. Its File Server role and SMB-signing requirement stay in place.

Pause - I'll come back to this later

Shut down FS01 to release its 4 GB of assigned memory. The registered VM remains available for the next project.

Return to VMware Workstation Pro from earlier.
Select FS01 from the existing virtual-machine list.
Return to the Windows session inside FS01.
Use the Windows shutdown control to shut down the guest.
Confirm that the guest has stopped in VMware Workstation Pro.
Keep FS01 registered in VMware Workstation Pro.
Keep both persistent virtual disks on your Mac.

FS01 stops using its assigned processors and memory. Its operating-system disk and data disk continue to consume Mac storage.

Delete - I don't want to use this again

Deleting FS01 permanently removes the server foundation you built. Choose this option only when you are certain that the VM will not be reused.

The cleanup order removes the domain trust before the virtual machine disappears. This prevents an abandoned computer account from remaining active.

Return to FS01 through VMware Workstation Pro from earlier.
Sign in to FS01 with an authorized domain administrative account.
Use the computer-name membership settings to remove FS01 cleanly from cloudseam.tech while the server is online.
Provide authorized domain credentials when Windows prompts you.
Restart FS01 when Windows prompts you.
Sign in with the local Administrator account.
Shut down FS01 from Windows.

FS01 no longer has active membership in cloudseam.tech. Its powered-off guest is ready for permanent removal.

Return to the domain controller from earlier.
Remove FS01 from Server Manager's All Servers pool.
Confirm that the virtual machine will not be reused.
Remove any remaining FS01 computer account from Active Directory.

FS01 no longer appears in the domain controller's Server Manager pool. No stale FS01 computer account remains in cloudseam.tech.

Return to VMware Workstation Pro from earlier.
Select the powered-off FS01 virtual machine.
Delete FS01 through VMware Workstation Pro's removal flow.
Choose the option that removes the associated virtual-disk files from your Mac.
Confirm that FS01 no longer appears in the virtual-machine list.

The 60 GB operating-system disk and 40 GB data disk no longer consume Mac storage. Deleting the guest also removes its File Server role.

The local SMB-signing policy disappears with the guest. The F: data volume is also removed.

Nice Work!

You made it! FS01 now provides a domain-joined file-server foundation for the rest of your enterprise file-services series.

You've learned how to:

Provision a dedicated member server with Windows Server 2022 Desktop Experience. Name it FS01. Connect it to the same virtual network as the domain controllers.
Expose broken Active Directory DNS discovery with an intentional lookup failure. Restore discovery by using both domain controllers as DNS servers. Give the server a stable IPv4 configuration. Prove the repair by seeing the domain controller locator records.
Build a separate data volume as an empty NTFS volume on F:. Join FS01 to cloudseam.tech with a healthy secure channel. Install the File Server role. Require inbound SMB signing.
Secret Mission: Add FS01 to a domain controller's Server Manager pool. Confirm its Online status. Inspect its role and storage inventory without opening the VMware console.

Your file-server foundation is ready. Ready to quiz yourself? Let's check what you remember.