Month: November 2015

Stop Brute Force Cold: How to Rename the Local Administrator via GPO | Lazy Admin Blog

Posted on Updated on

The “Administrator” account is a universal target. Because every Windows machine has one by default, hackers already have 50% of the login equation—the username. By renaming this built-in account across your entire Active Directory domain, you significantly lower the risk of automated brute-force attacks.

Best of all? You don’t have to touch a single workstation. We can do this globally using Group Policy Preferences (GPP).

Step 1: Create or Edit your GPO

  1. Open the Group Policy Management console (gpmc.msc).
  2. Create a new GPO (e.g., “Security – Rename Local Admin”) or edit an existing one linked to your target Workstations or Servers OU.
  3. Right-click the GPO and select Edit.

Step 2: Configure the Local User Preference

Navigate to the following path within the editor: Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups

  1. Right-click Local Users and Groups and select New > Local User.
  2. Configure the following settings in the dialog box:
    • Action: Select Update.
    • User name: Select Administrator (built-in) from the dropdown. (Using the built-in identifier ensures the rename works even if the account was previously renamed).
    • Rename to: Enter your new, non-obvious username (e.g., SrvManager_Admin).
    • Full name: Enter a descriptive name.
    • Password: You can optionally reset the password here, though using LAPS (Local Administrator Password Solution) is recommended for password management.

Step 3: Deployment & Verification

By default, Group Policy refreshes every 90 minutes. If you want to see the change immediately on a specific client, run the following command in an elevated prompt:

DOS

gpupdate /force

Is it working?

If the name hasn’t changed, use the GPResult tool to see if the policy is being applied to the computer object:

DOS

gpresult /r

Troubleshooting Tips:

  • OU Check: Ensure the Computer object is actually inside the OU where the GPO is linked.
  • Security Filtering: Verify that Authenticated Users or Domain Computers have “Read” and “Apply Group Policy” permissions in the GPO’s Delegation tab.
  • Replication: If some sites see the change and others don’t, check your Domain Controller replication status.

Why this is a “Lazy Admin” Win

Instead of using scripts or manual intervention, GPO Preferences handle the logic for you. If you ever need to change the name again, you update one field in the GPO, and the entire domain follows suit.

Forgot Your ESXi Root Password? Reset It Without Reinstalling (vCenter Hack) | Lazy Admin Blog

Posted on Updated on

We’ve all been there. You go to log into the DCUI or SSH into a host only to find the root password doesn’t work, and nobody documented the change.

According to VMware’s official stance, the only “supported” way to recover is a complete wipe and reinstall. But if your host is still managed by vCenter and you have Enterprise Plus licensing, there is a “lazy” (and highly effective) way out using Host Profiles.

How it works

When a host is added to vCenter, a special user called vpxa is created with full root privileges. We can use this existing “backdoor” to push a new configuration to the host, effectively overwriting the lost root password.


Step-by-Step Recovery

1. Extract the Profile

Right-click the “locked” host in the vSphere Web Client. Navigate to All vCenter Actions > Host Profiles > Extract Host Profile. Follow the wizard to create a template of that specific host’s configuration.

2. Edit the Security Settings

Go to Home > Host Profiles (under Management). Right-click your new profile and select Edit.

  • Expand Security and Services.
  • Expand Security Settings.
  • Click on Security Configuration.
  • In the dropdown, select: “Configure a fixed administrator password”.
  • Enter and confirm your new root password.

3. Attach and Remediate

  1. Go back to Hosts and Clusters, right-click the host, and select Host Profiles > Attach Host Profile. Select the one you just edited.
  2. Maintenance Mode: You must put the host into Maintenance Mode.
  3. Remediate: Right-click the host again, select Host Profiles > Remediate. If you skip Maintenance Mode, vSphere will block the operation.

4. Finish

Once the remediation task completes, the host will reboot. Your new root password is now active!


Important Limitations

  • Licensing: This requires Enterprise Plus. Standard or Essentials kits do not include Host Profiles.
  • Connectivity: The host must be currently “Connected” in vCenter. If the management agent has crashed or the host is “Not Responding,” this method will not work.

The “Lazy Admin” Verdict

Reinstalling an ESXi host means reconfiguring networking, storage, and scratch partitions. Using a Host Profile takes about 10 minutes and keeps your uptime (and sanity) intact.

The Clean Exit: How to Safely Remove Storage Devices from ESXi | Lazy Admin Blog

Posted on Updated on

In the world of storage, “unpresenting” a LUN is more than just a right-click. If you don’t follow the proper decommissioning workflow, ESXi will keep trying to talk to a ghost device, leading to host instability and long boot times.

Follow this definitive checklist and procedure to ensure your environment stays clean and APD-free.

The “Safe-to-Remove” Checklist

Before you even touch the unmount button, verify these 7 critical points:

  1. Evacuate Data: Move or unregister all VMs, snapshots, templates, and ISO images from the datastore.
  2. HA Heartbeats: Ensure the datastore is NOT being used for vSphere HA heartbeats.
  3. No Clusters: Remove the datastore from any Datastore Clusters or Storage DRS management.
  4. Coredump: Confirm the LUN isn’t configured as a diagnostic coredump partition.
  5. SIOC: Disable Storage I/O Control (SIOC) for the datastore.
  6. RDMs: If the LUN is an Raw Device Mapping, remove the RDM from the VM settings (select “Delete from disk” to kill the mapping file).
  7. Scratch Location: Ensure the host isn’t using this LUN for its persistent scratch partition.

Pro Tip: Check Scratch Location via PowerCLI

Use this script to verify your scratch config across a cluster:

PowerShell
$cluster = "YourClusterName"
foreach ($esx in Get-Cluster $cluster | Get-VMHost) {
Get-VMHostAdvancedConfiguration -VMHost $esx -Name "ScratchConfig.ConfiguredScratchLocation"
}

Step 1: Identify your NAA ID

You need the unique Network Address Authority (NAA) ID to ensure you are pulling the right plug.

  • Via GUI: Check the Properties window of the datastore.
  • Via CLI: Run esxcli storage vmfs extent list

Step 2: The Unmount & Detach Workflow

1. Unmount the File System

In the Configuration tab > Storage, right-click the datastore and select Unmount. If you are doing this for multiple hosts, use the Datastores view (Ctrl+Shift+D) to unmount from the entire cluster at once.

2. Detach the Device (The Most Important Step)

Unmounting removes the “logical” access, but Detaching tells the kernel to stop looking for the “physical” device.

  • Switch to the Devices view.
  • Right-click the NAA ID and select Detach.
  • The state should now show as Unmounted.

Note: Detaching is a per-host operation. You must perform this on every host that has visibility to the LUN to avoid APD states.


Step 3: Cleanup the SAN & Host

Once the state is “Unmounted” across all hosts, you can safely unmap/unpresent the LUN from your SAN array.

Permanent Decommissioning

To prevent “ghost” entries from appearing in your detached list, run these commands on the host:

  1. List detached devices: esxcli storage core device detached list
  2. Remove the configuration permanently: esxcli storage core device detached remove -d <NAA_ID>

Standard Windows Monitoring Threshold Parameters | Lazy Admin Blog

Posted on Updated on

Monitoring thresholds are often dictated by the Service Level Agreement (SLA) or Statement of Work (SoW) signed with your client. However, if you are setting up a new environment or looking for baseline recommendations, these industry standards are a great place to start.

The Performance Monitoring Matrix

Below are the typical thresholds used for enterprise Windows environments. These are designed to minimize “alert fatigue” while ensuring you have enough time to react before a service failure occurs.

MetricPolling IntervalWarning (Yellow)High/Critical (Orange)Alert/Emergency (Red)
CPU Utilization5 Minutes> 80% for 3 polls> 90% for 2 polls> 95% for 2 polls
Memory (Available MBytes)5 Minutes< 100 MB< 50 MB< 20 MB
Memory (Pages/sec)5 Minutes> 500> 1000> 5000
Disk Free Space (%)15 Minutes< 15%< 10%< 5%
Disk Queue Length5 Minutes> 2 per spindle> 5 per spindle> 10 per spindle
Network Utilization5 Minutes> 60%> 80%> 90%
Service Status1 MinuteN/AStopped (Manual)Stopped (Automatic)

Understanding “Remedy on Demand” (RoD) Integration

In many enterprise environments, these thresholds are tied directly to an ITSM tool like Remedy on Demand (RoD).

  • Warning levels usually trigger an email notification or a low-priority ticket.
  • Alert levels generate a high-priority incident in RoD, often triggering an automated page to the on-call engineer.

Key Considerations for Polling Intervals

  • Short Intervals (1-2 mins): Great for critical services, but increases the load on the monitoring server and the target agent.
  • Long Intervals (15-30 mins): Ideal for Disk Space or non-critical capacity trends.
  • The “3-Poll Rule”: To avoid alerts caused by temporary spikes (bursty CPU usage), set your monitoring tool to only trigger a ticket if the threshold is exceeded for 3 consecutive polling intervals.

A Sample Template:

Standard Windows Monitoring

The Master List: VMware vCenter Release & Build Number History (Updated 2026) | Lazy Admin Blog

Posted on Updated on

Version tracking is the backbone of lifecycle management. Whether you are patching against the latest security vulnerability or verifying compatibility for a backup agent, you need the exact build number.

Below is the comprehensive history of vCenter Server, from the cutting-edge vSphere 9.0 down to the legacy VirtualCenter 2.5.

vCenter Server 9.0 Build Numbers (Latest)

vSphere 9.0 represents the latest shift toward AI-integrated infrastructure and cloud-native operations.

NameVersionRelease DateBuild Number
vCenter Server 9.0.2.09.0.201/20/202625148086
vCenter Server 9.0.1.09.0.109/29/202524957454
vCenter Server 9.0 GA9.0.006/17/202524755230

vCenter Server 8.0 Build Numbers

The 8.0 Update 3 branch is the current stable “workhorse” for most enterprise environments.

NameVersionRelease DateBuild Number
vCenter Server 8.0 Update 3i8.0.3.0080002/24/202625197330
vCenter Server 8.0 Update 3h8.0.3.0070012/15/202525092719
vCenter Server 8.0 Update 3g8.0.3.0060007/29/202524853646
vCenter Server 8.0 Update 3e8.0.3.0050004/11/202524674346
vCenter Server 8.0 Update 38.0.3.0000006/25/202424022515
vCenter Server 8.0 Update 28.0.2.0000009/21/202322385739
vCenter Server 8.0 Update 18.0.1.0000004/18/202321560480
vCenter Server 8.0 GA8.0.0.1000010/11/202220519528

vCenter Server 7.0 Build Numbers

Note: vCenter for Windows was officially removed starting with version 7.0.

NameVersionRelease DateBuild Number
vCenter Server 7.0 Update 3w7.0.3.0250009/29/202524927011
vCenter Server 7.0 Update 3l7.0.3.0140003/30/202321477706
vCenter Server 7.0 Update 27.0.2.0000003/09/202117694817
vCenter Server 7.0 GA7.0.0.1010004/02/202015952498

Legacy vCenter Server Build Numbers (vSphere 4.0 – 6.7)

NameVersionRelease DateBuild Number
vCenter Server 6.7 Update 3w6.7.0.5800010/28/202424337536
vCenter Server 6.5 Update 3w6.5.0.4300007/04/202424045034
vCenter Server 6.0 Update 16.0 U109/10/20153018524
vCenter Server 5.5 Update 35.5 U309/16/20153000241
vCenter Server 5.1 Update 35.1 U312/04/20142306353
vCenter Server 5.0 GA5.0 GA08/24/2011456005
vCenter Server 4.1 GA4.1 GA07/13/2010259021
vCenter Server 4.0 GA4.0 GA05/21/2009162856
VirtualCenter 2.5.0 GA2.5.012/10/200764192

Quick Tips for the Lazy Admin

  1. Check via VAMI: For 6.7 and newer, go to https://<vcenter-ip>:5480. The version and build are right on the login screen.
  2. Compatibility: Before upgrading vCenter, check the VMware Interoperability Matrix. Just because vCenter 9.0 is out doesn’t mean your older ESXi 6.7 hosts can talk to it!
  3. VCSA Migration: If you are still on version 6.5 or 6.7, your next step is a migration to the Appliance (VCSA). There is no “in-place” upgrade for Windows-based vCenter to 7.0+.

#VMware #vSphere9 #vCenter #SysAdmin #Virtualization #Datacenter #LazyAdmin #BuildNumbers #ITOps #PatchManagement