Systems Administration

This procedure verifies that the Windows Server domain controller is running and that key domain services are available.

hostname

ipconfig /all

Check that the server has the expected static IP address, DNS settings, and domain configuration.

Open Server Manager and confirm the following roles or tools are available:

• Active Directory Domain Services
• DNS
• DHCP
• Group Policy Management

Check domain health from an elevated Command Prompt or PowerShell window:

dcdiag

If issues appear, review the error messages, confirm network configuration, check DNS resolution, and verify that required services are running.

This procedure creates a basic domain user account in the appropriate organizational unit.

1. Open Active Directory Users and Computers.
2. Navigate to the appropriate organizational unit.
3. Right-click the OU and select New > User.
4. Enter the user’s first name, last name, and logon name.
5. Set a temporary password.
6. Select whether the user must change the password at next logon.
7. Confirm the account was created in the correct OU.

After creating the user, assign access using security groups rather than applying permissions directly to the user account.

Useful PowerShell-style check:

Get-ADUser username -Properties MemberOf

This procedure resets a user password when the user cannot log in or has forgotten their password.

1. Confirm the user’s identity.
2. Open Active Directory Users and Computers.
3. Search for the user account.
4. Right-click the account and select Reset Password.
5. Enter a temporary password.
6. Select User must change password at next logon, if appropriate.
7. Confirm whether the account is locked, disabled, or expired.

If the user still cannot log in, check network connectivity, domain controller availability, DNS configuration, and whether the issue affects only one workstation.

This procedure unlocks a user account after too many failed login attempts.

1. Open Active Directory Users and Computers.
2. Find the affected user account.
3. Open the account properties.
4. Check whether the account is locked.
5. Unlock the account and apply the change.

If the account locks again, investigate possible causes:

• Old password saved on another workstation
• Mapped drive using cached credentials
• Mobile device or mail client using an old password
• Scheduled task or service using outdated credentials
• Repeated login attempts from another machine

The goal is not just to unlock the account, but to identify what is repeatedly causing the lockout.

This procedure grants access by adding a user to an existing Active Directory security group.

1. Confirm which group controls access to the resource.
2. Open Active Directory Users and Computers.
3. Find the user account.
4. Open the user’s properties and go to Member Of.
5. Add the appropriate security group.
6. Ask the user to log off and back on so the new group membership is applied to their logon token.

If access still fails, check nested groups, replication delay, share permissions, NTFS permissions, explicit deny permissions, and whether the user is accessing the correct resource path.

Access should be granted using groups whenever possible instead of direct user permissions.

This procedure is used when a domain user cannot log in to a Windows workstation.

First determine the scope:

• Does the issue affect one user or multiple users?
• Does it happen on one workstation or all workstations?
• Can other users log in to the same computer?
• Can the affected user log in to another computer?

Check the account:

• Locked account
• Disabled account
• Expired password
• Expired account
• Incorrect username or domain

Check the workstation:

ipconfig /all

ping <domain-controller>

nslookup <domain-name>

If the workstation cannot locate the domain controller, check DNS settings first.

If only one workstation is affected, consider cached credentials, local profile issues, network connectivity, or domain trust relationship problems.

This procedure is used when a user cannot access a shared folder or mapped network drive.

First determine the scope:

• Can other users access the same folder?
• Can the affected user access it from another computer?
• Is the problem with one folder, one share, or all network shares?
• What exact error message appears?

Check the basics:

ping <file-server>

nslookup <file-server>

Then review access control:

• Security group membership
• Share permissions
• NTFS permissions
• Explicit deny permissions
• Mapped drive path
• Cached credentials

For file shares, effective access depends on both share permissions and NTFS permissions. Avoid granting broad permissions just to make the problem disappear.

This procedure verifies that domain clients are using the correct DNS server and can resolve domain resources.

On a client workstation, check network configuration:

ipconfig /all

Confirm that the workstation is using the domain DNS server rather than an external DNS server.

Test name resolution:

nslookup <domain-name>

nslookup <domain-controller>

If DNS fails, check:

• Client DNS server settings
• DHCP scope options
• DNS service status on the server
• Forward and reverse lookup zones
• Recent network or IP address changes

DNS problems often appear as login, Group Policy, or shared resource problems.

This procedure is used when a workstation does not receive the expected IP configuration.

On the client workstation:

ipconfig /all

Look for:

• Valid IP address
• Correct subnet mask
• Correct default gateway
• Correct DNS server
• APIPA address

Renew the lease if appropriate:

ipconfig /release

ipconfig /renew

On the server, check the DHCP scope, available addresses, reservations, exclusions, and scope options.

If multiple clients fail to receive addresses, check the DHCP service, network connectivity, VLAN/subnet configuration, and whether the scope has available leases.

This procedure is used when a workstation or user does not appear to be receiving the expected Group Policy settings.

On the client workstation, force a Group Policy update:

gpupdate /force

Check applied policy results:

gpresult /r

For a more detailed report:

gpresult /h gp-report.html

If a policy is not applying, check:

• Whether the user or computer is in the correct OU
• Whether the GPO is linked to the correct OU
• Security filtering
• WMI filtering, if used
• Inheritance and blocked inheritance
• DNS and domain controller connectivity

Group Policy troubleshooting should start with scope.

This procedure adds a Windows client machine to the Active Directory domain.

1. Confirm the workstation has network connectivity.
2. Confirm the workstation is using the domain DNS server.
3. Open system settings and select the option to rename or join a domain.
4. Enter the domain name.
5. Provide authorized domain credentials when prompted.
6. Restart the workstation.
7. Confirm the computer object appears in Active Directory.
8. Move the computer object to the correct OU if needed.

If domain join fails, check DNS first. A client that cannot resolve the domain controller will usually fail to join the domain.

ipconfig /all

nslookup <domain-name>

ping <domain-controller>

This checklist is used when domain services or client access are not working as expected.

1. Confirm the domain controller is powered on and reachable.
2. Check the domain controller IP address and DNS settings.
3. Confirm key services are running.
4. Check client IP configuration with ipconfig /all.
5. Confirm the client is using the domain DNS server.
6. Test name resolution with nslookup.
7. Determine whether the issue affects one user, one computer, or many users.
8. Check account status, group membership, and permissions.
9. Check Group Policy application with gpresult /r.
10. Review relevant logs and document the issue, cause, fix, and follow-up steps.