How to Install and Configure SNMP on Windows Server 2019 Using PowerShell

Introduction

Simple Network Management Protocol (SNMP) is widely used for monitoring servers, network devices, and infrastructure components. In Windows Server 2019, SNMP is available as a Windows feature and can be fully installed and configured using PowerShell, making it ideal for automation and audit-compliant deployments. We widely use it remotely monitor servers historical performance unclouding DUDE, LIBRENMS and other tools.

This article explains how to install SNMP, configure the community string, and allow access from any host using PowerShell only.

---

Prerequisites

Before proceeding, ensure:

• You are logged in as a Local Administrator

• PowerShell is running as Administrator

• Windows Server version is 2019

---

Step 1: Install SNMP Service Using PowerShell

Run the following command to install the SNMP service along with management tools:

Install-WindowsFeature SNMP-Service -IncludeManagementTools


To verify installation:

Get-WindowsFeature SNMP-Service


The installation state should display as Installed.

---

Step 2: Configure SNMP Community String

SNMP community strings are stored in the Windows registry.
In this example, we configure a READ-ONLY community string named public.

New-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities" `
-Name "public" `
-PropertyType DWORD `
-Value 4 `
-Force


Community Permission Values

• 4 → Read-Only

• 8 → Read-Write

• 1 → None

---

Step 3: Allow SNMP Access from Any Host

By default, Windows restricts SNMP access to specific managers. To allow SNMP queries from any host, remove existing restrictions. (for testing , but later ensure you enter your management / monitoring ip so that it should be restricted.)

Remove current permitted managers (if any):

Remove-Item `
-Path "HKLM:\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\PermittedManagers" `
-Recurse `
-Force `
-ErrorAction SilentlyContinue


Recreate an empty key:

New-Item `
-Path "HKLM:\SYSTEM\CurrentControlSet\Services\SNMP\Parameters" `
-Name "PermittedManagers" `
-Force


An empty PermittedManagers key means SNMP access is allowed from all hosts.

---

Step 4: Restart SNMP Service

Apply changes by restarting the SNMP service:

Restart-Service SNMP


Verify service status:

Get-Service SNMP


---

Step 5 (Optional): Configure Windows Firewall

If SNMP polling does not work, ensure UDP port 161 is allowed:

New-NetFirewallRule `
-DisplayName "Allow SNMP UDP 161" `
-Direction Inbound `
-Protocol UDP `
-LocalPort 161 `
-Action Allow


---

Testing SNMP Connectivity

From your monitoring or management server, test SNMP access:

snmpwalk -v2c -c public <server-ip>


A successful response confirms that SNMP is working correctly.

---

Security Considerations

Allowing SNMP access from any host is not recommended for production environments unless additional controls are in place. Consider:

• Restricting SNMP access using firewall rules

• Using strong, non-default community strings

• Migrating to SNMPv3 where encryption and authentication are required

---

Conclusion

Using PowerShell to install and configure SNMP on Windows Server 2019 provides a fast, repeatable, and audit-friendly approach. This method is especially useful for system administrators managing large environments or following strict SOPs.

How to Allow Support Users to Rename Domain Computers (Without Domain Admin Rights)

Renaming domain-joined computers is a routine IT support task — but granting Domain Admin rights just for this purpose is a security anti-pattern.

This guide explains the correct and Microsoft-supported way to allow IT support engineers to rename computers using PowerShell, without elevating them to Domain Admins, while maintaining proper security boundaries and auditability.

---

Common Misconception

“IT support engineers are already local admins on PCs, so they should be able to rename domain computers.”

❌ Incorrect

• Being a local administrator only allows changes on the local system.
• Renaming a domain-joined computer also modifies the computer object in Active Directory, which requires AD-level permissions.

---

Correct Approach (Best Practice)

✔ Delegate limited Active Directory permissions

Instead of broad admin access, we delegate only what is required:

• Rename computer objects
• Update DNS hostname
• Update Service Principal Names (SPNs)

Nothing more.

---

High-Level Design

Component	Purpose
AD Security Group	Controls who can rename computers
OU-level Delegation	Limits scope to specific computers
PowerShell Rename-Computer	Supported rename mechanism
Local Admin Rights	Required on the target PC

---

Step 1: Create a Dedicated AD Security Group

Example group name:

• IT-Support-ComputerRename

Add your IT Support User accounts to this group.

Tip: Do not assign permissions directly to users — always use a group.

---

Step 2: Delegate Computer Rename Permissions in Active Directory

1. Open Active Directory Users and Computers
2. Right-click the OU containing computer accounts
3. Select Delegate Control
4. Add the group:
   IT-Support-ComputerRename

5. Choose Create a custom task to delegate
6. Select:
   • ☑ Only the following objects in the folder
   • ☑ Computer objects
7. Permissions:
   • ☑ Read
   • ☑ Write
8. Select the following permissions:
   • ☑ Validated write to DNS host name
   • ☑ Validated write to service principal name
   • ☑ Write account restrictions

Finish the wizard.

✅ Delegation is now limited, secure, and auditable.

---

Step 3: Ensure Local Administrator Rights

IT support engineers must also be:

• Members of the Local Administrators group on the target computer
  (via GPO, Intune, or manual assignment)

This is required to execute the rename locally.

---

Step 4: PowerShell Command for Support Users

IT support engineers can now rename computers without supplying domain credentials, using their own login:

Rename-Computer -ComputerName "OLD-PC-NAME" -NewName "NEW-PC-NAME" -Force -Restart


Requirements

• Run PowerShell as Administrator
• Computer must be online and reachable
• Rename triggers an automatic reboot

---

Is -DomainCredential Required?

No, as long as:

• The support user is logged in with their support ID
• The support ID is in the delegated AD group
• PowerShell is run as Administrator

The command uses the current security context.

---

What This Design Prevents

Risk	Mitigation
Over-privileged support accounts	No Domain Admin rights
Credential leakage	No hardcoded credentials
OU-wide damage	Delegation limited to computers
SPN / DNS corruption	Validated writes only

---

Auditing & Logging

Computer rename events are logged in Domain Controller Security Logs:

• Event ID 4742 – Computer account was changed

This makes the activity fully traceable for audits.

---

Recommended Naming Controls

For production environments:

• Enforce naming standards via SOP
• Restrict delegation to specific OUs only
• Require ticket/reference number before rename
• Log changes in CMDB or asset inventory

---

Summary

✔ Local admin rights alone are not enough
✔ Delegated AD permissions are the correct solution
✔ IT support engineers can safely rename computers
✔ No Domain Admin exposure
✔ Fully auditable and compliant

---

Final Note

This approach aligns with least privilege, enterprise security, and Microsoft best practices — making it suitable for regulated and audit-driven environments.

Regards
Syed Jahanzaib