SysAdmin Guide

Setting Up Microsoft Entra Connect (Step-by-Step) | Lazy Admin Blog

Posted on Updated on

Why do manual user management when you can let a sync engine do the heavy lifting?

If you’re still manually creating users in both on-premises Active Directory and the Microsoft 365 portal, stop. You’re working too hard. Microsoft Entra Connect (formerly Azure AD Connect) is the “bridge” that syncs your local identities to the cloud. Set it up once, and your users get one identity for everything.

1. The “Pre-Flight” Checklist (Don’t skip this!)

The biggest mistake admins make is running the installer before the environment is ready. To be truly “lazy,” do the prep work so the installation doesn’t fail midway.

  • Server: A domain-joined Windows Server 2016 or later (2022 is recommended).
  • Hardware: Minimum 4GB RAM and a 70GB hard drive.
  • Permissions: * Local: You need to be a Local Admin on the sync server.
    • On-Prem: An Enterprise Admin account for the initial setup.
    • Cloud: A Global Administrator or Hybrid Identity Administrator account in Entra ID.
  • Software: .NET Framework 4.7.2 or higher and TLS 1.2 enabled.

Pro Tip: Run the Microsoft IdFix tool first. It finds duplicate emails and weird characters in your AD that would otherwise break the sync.


2. Step-by-Step Installation

Download the latest version of the Entra Connect MSI here.

Step A: The Express Route

  1. Launch AzureADConnect.msi.
  2. Agree to the terms and click Use Express Settings. (Note: Use “Custom” only if you have multiple forests or need specific attribute filtering).
  3. Connect to Entra ID: Enter your Cloud Admin credentials.
  4. Connect to AD DS: Enter your Enterprise Admin credentials.
  5. Entra ID Sign-in: Ensure your UPN suffixes match. If your local domain is corp.local but your email is lazyadminblog.com, you need to add lazyadminblog.com as a UPN suffix in AD.

Step B: The “Staging Mode” Safety Net

Before you hit install, you’ll see a checkbox for “Start the synchronization process when configuration completes.” If you are replacing an old server or are nervous about what will happen to your 5,000 users, check the “Enable staging mode” box. This allows the server to calculate the sync results without actually exporting anything to the cloud. You can “peek” at the results before going live.


3. Post-Setup: The “Lazy” Health Check

Once installed, the sync runs every 30 minutes by default. You don’t need to babysit it, but you should know how to check it:

  • The Desktop Tool: Open the Synchronization Service Manager to see a green “Success” status for every run.
  • The PowerShell Way: To force a sync right now (because you’re too impatient for the 30-minute window), run:PowerShellStart-ADSyncSyncCycle -PolicyType Delta

4. Troubleshooting Common “Gotchas”

  • “Top-level domain not verified”: You forgot to add your domain (e.g., https://www.google.com/search?q=myblog.com) to the Entra ID portal.
  • “Object Synchronization Triggered Deletion”: By default, Entra Connect won’t delete more than 500 objects at once. This is a safety feature to stop you from accidentally wiping your cloud directory. If you intended to delete them, you’ll need to disable the export deletion threshold.

The “Lazy Admin” Sync Monitor Script

Copy and save this as Monitor-EntraSync.ps1 on your sync server.

# --- CONFIGURATION ---
$SMTPServer = "smtp.yourrelay.com"
$From = "EntraAlert@lazyadminblog.com"
$To = "you@yourcompany.com"
$Subject = "⚠️ ALERT: Entra ID Sync Failure on $(hostname)"
# --- THE LOGIC ---
# Import the AdSync module (usually already loaded on the server)
Import-Module ADSync
# Get the statistics of the very last sync run
$LastRun = Get-ADSyncRunProfileResult | Sort-Object StartDateTime -Descending | Select-Object -First 1
# Check if the result was NOT 'success'
if ($LastRun.Result -ne "success") {
    $Body = @"
    The last Entra ID Sync cycle failed!
    
    Server: $(hostname)
    Run Profile: $($LastRun.RunProfileName)
    End Time: $($LastRun.EndDateTime)
    Result: $($LastRun.Result)
    
    Please log in to the Synchronization Service Manager to investigate.
"@
    # Send the alert
    Send-MailMessage -SmtpServer $SMTPServer -From $From -To $To -Subject $Subject -Body $Body -Priority High
}

🛠️ How to set it up (The Lazy Way)

To make this fully automated, follow these steps:

  1. Create a Scheduled Task: Open Task Scheduler on your Entra Connect server.
  2. Trigger: Set it to run every hour (or every 30 minutes to match your sync cycle).
  3. Action: * Program/script:powershell.exe
    • Add arguments: -ExecutionPolicy Bypass -File "C:\Scripts\Monitor-EntraSync.ps1"
  4. Security Options: Run it as SYSTEM or a Service Account that has local admin rights so it can access the ADSync module.

Why this is better than “Default” monitoring:

  • No Noise: You only get an email if there is an actual problem.
  • Proactive: You’ll likely know the sync is broken before your users start complaining that their new passwords aren’t working.
  • Zero Cost: No need for expensive third-party monitoring tools for a single-server task.

References & Further Reading

ESXi Multipathing Decoded: MRU, Fixed, and Round Robin

Posted on Updated on

When you present a LUN to an ESXi host, the Native Multipathing (NMP) engine automatically assigns a policy based on the type of storage array detected. However, as an admin, you need to understand why a policy was chosen—and when you should manually intervene.

1. Most Recently Used (MRU)

Best For: Active/Passive Arrays. MRU selects the first working path it finds at boot. If that path fails, it switches to a standby path.

  • Key Behavior: It does not fail back. Even if the original path becomes healthy again, the host stays on the current path. This prevents “path thrashing” on Active/Passive arrays where switching controllers is an expensive operation.

2. Fixed

Best For: Active/Active Arrays. The Fixed policy uses a specific “Preferred Path.” If the preferred path fails, it moves to an alternative.

  • Key Behavior: It does fail back. As soon as that designated preferred path is back online, the host immediately switches back to it.

3. Round Robin (RR)

Best For: Load Balancing (Active/Active or ALUA). Round Robin rotates through all available paths to distribute the I/O load.

  • Active/Active: Uses every available path.
  • Active/Passive: Only uses all paths leading to the active controller.

Note: For Microsoft Failover Clusters (MSCS), Round Robin is only supported on ESXi 5.5 and later.

4. Fixed with Array Preference (FIXED_AP)

Introduced in ESXi 4.1 for ALUA-capable arrays, this policy lets the storage array tell the host which path is the “optimal” one.

  • Note: This was removed in ESXi 5.0 in favor of letting the NMP automatically select MRU or Fixed based on the array’s ALUA response.

⚠️ Critical Warnings for Admins

  1. Don’t Fight the NMP: VMware generally warns against manually changing a LUN from Fixed to MRU. The host chooses the policy based on the hardware it detects; forcing a change can lead to instability.
  2. Verify Vendor Support: Round Robin is powerful but not supported by every array. Always check the VMware Compatibility Guide before making it your default.
  3. MSCS Limitations: If you are virtualizing SQL clusters or other failover clusters, double-check your ESXi version before toggling Round Robin, or you risk losing disk heartbeat connectivity.

#VMware #ESXi #StorageAdmin #vSphere #Multipathing #SysAdmin #ITPro #Virtualization #LazyAdmin #DataCenter #StorageTips

Demystifying Cisco UCS Monitoring: Manager vs. Standalone C-Series

Posted on Updated on

Whether you are managing a massive farm of B-Series blades or a handful of standalone C-Series rack servers, Cisco UCS provides a sophisticated, stateful monitoring architecture. Understanding how this “Queen Bee” and “Worker Bee” relationship works is the key to reducing alert fatigue and maintaining 100% uptime.

🏗️ The Architecture: DME and Application Gateways

The core of UCS monitoring relies on three primary components that translate raw hardware signals into human-readable data.

1. Data Management Engine (DME)

Think of the DME as the Queen Bee. It is the central brain that maintains the UCS XML Database. This database is the “Single Source of Truth” for your entire domain, housing inventory details, logical configurations (pools/policies), and current health states.

2. Application Gateways (AG)

The AGs are the Worker Bees. These are software agents that communicate directly with hardware endpoints (blades, chassis, I/O modules). They monitor health via the CIMC (Cisco Integrated Management Controller) and feed that data back to the DME in near real-time.

3. Northbound Interfaces

These are your outputs. You have Read-Only interfaces like SNMP and Syslog for external monitoring, and the XML API which is a Read-Write interface, allowing you to both monitor health and push configuration changes.


🚨 The Fault Lifecycle: Managing “State”

Cisco UCS doesn’t just send “fire and forget” alerts. It uses a stateful fault model. Faults are objects that transition through a lifecycle to prevent “flapping”—where a minor glitch sends dozens of emails in a minute.

  • Active: The problem is occurring now.
  • Soaking: The issue cleared quickly, but the system is waiting to see if it reoccurs before notifying you.
  • Flapping: The fault is clearing and reoccurring in rapid succession.
  • Cleared: The issue is fixed, but the record is retained briefly for your attention.
  • Deleted: The fault is finally purged once the retention interval expires.

✅ Best Practices for the “Lazy Admin”

1. Filter out FSM Faults

In UCS Manager, Finite State Machine (FSM) faults are almost always transient. They occur during a task transition—like a server taking a bit too long to finish BIOS POST during a profile association.

The Rule: Focus your alerting on Major and Critical severities that are NOT of type FSM. This will eliminate about 80% of your monitoring “noise.”

2. Leverage Consistency

One of the best features of the UCS ecosystem is that Standalone C-Series and UCS Manager use the same MIBs and Fault IDs. If you have an NMS (Network Management System) set up for your blades, adding standalone rack servers is seamless because the data structure is identical.

3. Use Fault Suppression

Doing maintenance? Don’t let your monitoring system scream at you. Use the Fault Suppression feature (added in UCSM 2.1) to silence alerts on a specific blade or rack server while you are working on it.

4. The XML API Advantage

For standalone C-Series servers, the XML API is the preferred monitoring method. It supports Event Subscription, which proactively “pushes” alerts to your management tool rather than forcing the tool to “pull” or poll for data constantly.

CiscoUCS #SysAdmin #DataCenter #Networking #Cisco #ITPro #ServerMonitoring #LazyAdmin #Automation #TechTips

How to Change the Static IP Address of a Windows Domain Controller

Posted on Updated on

Whether you are re-IPing a subnet or moving a server to a new VLAN, changing a Domain Controller’s IP address requires more than just updating the NIC settings. If DNS records don’t update correctly, users won’t be able to log in, and replication will fail.

Prerequisites

  • Credentials: You must be a member of the Domain Admins group.
  • Access: Log on locally to the system console. If you lose network connectivity during the change, you may need to boot into DSRM to recover.

Step-by-Step: Changing the IP Address

  1. Open Network Connections: Right-click My Network Places (or Network in newer versions) and click Properties.
  2. Edit Adapter: Right-click your Local Area Connection and select Properties.
  3. TCP/IP Settings: Double-click Internet Protocol (TCP/IP).
  4. Update Addresses:
    • Enter the new IP address, Subnet mask, and Default gateway.
    • Update the Preferred and Alternate DNS servers.
    • Note: Usually, a DC points to itself (127.0.0.1) or a partner DC for DNS.
  5. WINS (Optional): If your environment still uses WINS, click Advanced > WINS tab and update any static WINS server entries.
  6. Apply: Click OK until all dialog boxes are closed.

Critical Step: Post-Change Registration

Once the IP is changed, Windows needs to tell the rest of the domain where the DC is now located. Do not skip these commands.

Open a Command Prompt and run:

  1. Register DNS Records:DOSipconfig /registerdns This forces the DC to update its ‘A’ (Host) record in DNS.
  2. Fix Service Records:DOSdcdiag /fix This ensures that vital SRV records (which clients use to find the DC) are updated to point to the new IP.

Potential Pitfalls: Mapped Drives and Hardcoded IPs

Changing the IP settings won’t affect shared permissions, but it will break any connection made via IP address rather than hostname.

  • Avoid This: net use g: \\192.168.0.199\data (This breaks after the change).
  • Do This: net use g: \\DC1\data (This continues to work regardless of the IP).

The LazyAdmin Lesson: Always use DNS names (Hostnames) for your resources. It saves you from manual updates every time a server moves!

ActiveDirectory #SysAdmin #WindowsServer #Networking #IPAddress #ITPro #DNS #Troubleshooting #LazyAdmin #ServerAdmin