Category: Networking

Reveal Known WiFi Password via Command Line

To reveal the password for a known Wi-Fi network (SSID) in Windows 11 using the command line, follow these steps:

  1. Open Command Prompt as Administrator:
    • Click on the Start menu, type cmd or Command Prompt in the search bar.
    • Right-click on Command Prompt from the search results and select Run as administrator.
  2. List All Saved Wi-Fi Profiles:
    • In the Command Prompt window, type the following command and press Enter:sqlCopyEditnetsh wlan show profiles
    • This command will display a list of all Wi-Fi profiles that your computer has connected to previously.
  3. Display the Password for a Specific Wi-Fi Profile:
    • Identify the Wi-Fi profile name (SSID) for which you want to reveal the password from the list generated in the previous step.
    • Type the following command, replacing Your_SSID with the name of your Wi-Fi network, and press Enter:pgsqlCopyEditnetsh wlan show profile name="Your_SSID" key=clear
    • In the output, scroll to the Security settings section.
    • Locate the line labeled Key Content; the value next to it is the Wi-Fi password.

Example: If your Wi-Fi network name is HomeNetwork, the command would be:

pgsqlCopyEditnetsh wlan show profile name="HomeNetwork" key=clear

The output will display information about the profile, and under Security settings, you’ll find:

yamlCopyEditSecurity settings:
    ...
    Key Content            : [Your Wi-Fi Password]

Note: Ensure you have administrative privileges to execute these commands. This method works for Wi-Fi networks that your computer has previously connected to and saved.

Ultrex LTT Partners Bid process (electrical)

🧰 Ultrex IT – Low Voltage Bid Process (Backup Vendor)

Purpose

To streamline how we gather and send information to LTT Partners (Harper Wimble’s team) or other low-voltage vendors for cable run bids—especially when no walkthrough is needed.


1. Overview

Vendor:

  • Company: LTT Partners (Backup Low Voltage Team)
  • Primary Contact: Harper Wimble – harper@lttpartners.com

Goal:
To request bids for low voltage runs (cameras, access control, etc.) without needing an on-site walkthrough by providing complete documentation, photos, and videos.


2. Preparation Before Requesting a Bid

✅ Gather Required Information

Make sure you collect and/or create the following materials:

  • PDF floor plans of the building
    • If available, mark up with:
      • Camera locations
      • Door access control points
      • Any other wire run endpoints
  • Photos and videos
    • Walk through each area where runs will go
    • Show key locations (IDF, ceiling type, entry points, etc.)
  • Picture of IDF (network closet)
    • Show racks, switches, and available ports
  • Note ceiling type (e.g., drop ceiling, drywall, open industrial)
  • Confirm if lift is needed (based on ceiling height or access)
  • Document mounting heights
    • Interior cameras
    • Exterior cameras
  • Identify system type
    • Which camera or access control system is being installed (e.g., UniFi Protect, Verkada, etc.)
  • Doors requiring electrification
    • List which doors will need power for access control
  • Preferred wire path runs (if known)
    • Example: “Follow HVAC chase” or “Run through plenum ceiling above hallways”
  • Switch information
    • Note if there’s an open switch port or if they’ll need to provide one
  • Installation hours
    • Confirm if there are preferred or restricted working hours
  • Drilling requirements
    • Note surfaces like brick, sheetrock, concrete, etc.
  • Device onboarding responsibility
    • Confirm whether Ultrex IT or the vendor handles final setup/configuration

3. Sending the Bid Request

📧 Email Template

To: harper@lttpartners.com

Defederate Steps from GoDaddy to MS365

A few things to do first. Make sure you can login with the godaddy admin account to Portal.Azure.com
And change the password for the “admin@net…..” account. This will be your new admin account to login into MS365

1. PowerShell Execution Policy:

Problem: By default, PowerShell often blocks running scripts.

Check: Run Get-ExecutionPolicy in PowerShell.

Solution: If it shows “Restricted,” run Set-ExecutionPolicy Bypass -Scope Process.

This temporarily allows scripts to run in the current PowerShell session.

2. Install Microsoft Graph Module:

Run: Install-Module Microsoft.Graph -Scope CurrentUser -Repository PSGallery -Force in PowerShell (as administrator).

Wait: This may take time. Wait until it returns to the system prompt.

3. Run the De-federation Script:

Run the provided script from the blog post. 

https://docs.tminus365.com/configurations/godaddy/defederating-godaddy-365

Here is the primary Script to run

Write-Host “Checking for MSGraph module…”

$Module = Get-Module -Name “Microsoft.Graph.Identity.DirectoryManagement” -ListAvailable

if ($Module -eq $null) {

        Write-Host “MSGraph module not found, installing MSGraph”

        Install-Module -name Microsoft.Graph.Identity.DirectoryManagement

    }

Connect-MgGraph -Scopes “Directory.Read.All”,”Domain.Read.All”,”Domain.ReadWrite.All”,”Directory.AccessAsUser.All”

#Enter the Admin credentials from “Become a tenant Admin in GoDaddy”

Get-MgDomain

#See that the domain is “federated”#

Update-MgDomain -DomainId “<InsertFederatedDomain>” -Authentication Managed

Prompts:

You might be asked about allowing network paths and untrusted modules.

Answer “Yes” or “Yes to All” to these prompts.

You will be asked to enter your godaddy admin credentials.

Action: The script will change the domain from “federated” to “managed.”

Note – Don’t close Powershell yet!

4. Post-Script Actions:

Log in to the Microsoft 365 admin center.

Remove GoDaddy from the partner list.

Reset all the logins for the users.

Remove Global Admin from any account not freshly created during this process.

Assign proper licenses for users- often they’ll come over with only exchange online licenses. 

When all is done. Run Disconnect-MgGraph  in powershell. This will disconnect from the domain so the computer can do a different migration without issues. 

Changing network connection profile to private vs public by powershell in 2 commands

Get-NetConnectionProfile

Set-NetConnectionProfile -InterfaceIndex <InterfaceIndex> -NetworkCategory Private

Set-NetConnectionProfile -InterfaceIndex 16 -NetworkCategory Private

Get-NetConnectionProfile

To change a network from Public to Private you can use several methods. Since the graphical interface in Server editions doesn’t always provide this option, PowerShell is often the most straightforward approach.


🔧 Using PowerShell

  1. Open PowerShell as Administrator:
    • Right-click the Start button and select Windows PowerShell (Admin).
  2. Identify the Network Interface:
Get-NetConnectionProfile
  1. This command lists all network interfaces and their current profiles.
  2. Change the Network Category:Replace <InterfaceIndex> with the actual index number of your network adapter.
Set-NetConnectionProfile -InterfaceIndex <InterfaceIndex> -NetworkCategory Private
  1. For example, if your interface index is 8:
Set-NetConnectionProfile -InterfaceIndex 8 -NetworkCategory Private
  1. Verify the Change:
Get-NetConnectionProfile
  1. Ensure that the NetworkCategory is now set to Private.

Phone Notes for Comcast BVE on VLANs

Comcast BVE (Business VoiceEdge) Phones – VLAN & Provisioning Guide

Overview

When working with Comcast Business VoiceEdge (BVE) VoIP phones, it’s important to understand how their provisioning device interacts with the network. Unlike a traditional PBX, Comcast deploys a small network appliance (often a blue box) that handles phone provisioning and configuration. While not a full PBX, this device is critical for the phones to function properly.

VLAN Requirements

  • The Comcast provisioning appliance must be on the same VLAN as the phones.
  • If the phones are isolated on their own VLAN (common when inheriting networks from other IT providers), the provisioning device will not communicate correctly, resulting in nonfunctional phones.

Real-World Issues Encountered

  • JT Law and CFM both experienced outages due to this misalignment.
  • In both cases, the provisioning box was on a different VLAN than the phones, breaking the setup until corrected.

Troubleshooting & Fix

  • Since Ultrex does not have login access to Comcast’s on-site provisioning device, configuration must be handled at the network switch/router level.
  • The fastest and most reliable solution is to adjust port profiles at the switch/router so the provisioning device and phones share the same VLAN.
  • Do not rely on Comcast support for VLAN adjustments:
    • It is often faster to fix locally than wait for Comcast.
    • Many Comcast techs are not familiar with VLAN management and may be unable to assist effectively.

Key Takeaways

  • Always confirm the provisioning device is on the same VLAN as the phones.
  • Handle VLAN changes locally via port profile assignment rather than Comcast.
  • This lesson has now been learned multiple times—making proactive VLAN checks a standard step when deploying or troubleshooting Comcast BVE phones.

Network Magic Fix: automated script to disable then re-enable network drivers

Here’s how you make an automated script to disable then re-enable network drivers:

In either Notepad or Notepad++, create a new file.

Copy and paste this text below into your program:

# Disable all network adapters
Get-NetAdapter | Disable-NetAdapter -Confirm:$false

# Wait for 5 seconds
Start-Sleep -Seconds 5

# Enable all network adapters
Get-NetAdapter | Enable-NetAdapter -Confirm:$false

Once you’ve pasted it in there, go to File and select “Save As”

Name the file DisableEnableNetwork.ps1 and change the File Type to All.

Make sure this get’s saved somewhere that isn’t going to be easily accessible by clients.

Next, on your desktop home screen, right click anywhere on the screen, and select “New” in the drop down.

Click “Shortcut”

In the box that shows up, in the location field enter:

powershell.exe -ExecutionPolicy Bypass –File “C:\path\to\DisableEnableNetwork.ps1”

Click Next

Give the shortcut a cool, hip name like “Network Magic Fix”, “Internet Fix Voodoo” or “Wifi Problem Solver” and hit save.

Now when the shortcut is double clicked, it’ll disable then re-enable all network drivers which should fix the problem utun has been causing (until it does it again, then click the shortcut again)

Setting up WireGuard VPN Server on pfSense Router and Client Devices

Setting Up WireGuard VPN on pfSense: A Comprehensive Guide

This guide provides step-by-step instructions for configuring WireGuard VPN on a pfSense router, including detailed explanations of each configuration step.

Created 6/4/25 by Andrae


Prerequisites

  • pfSense version 2.5.2 or newer
  • Administrative access to the pfSense web interface
  • Basic understanding of networking conceptsivpn.netdeepwiki.com

Step 1: Install the WireGuard Package

  1. Log in to the pfSense web interface.
  2. Navigate to System > Package Manager > Available Packages.
  3. Search for WireGuard and click Install.
  4. Wait for the installation to complete.ivpn.net

Step 2: Create a WireGuard Tunnel

  1. Go to VPN > WireGuard.
  2. Click Add Tunnel.
  3. Configure the tunnel:
    • Enable: Checked
    • Description: e.g., WireGuard VPN
    • Listen Port51820 (default)
    • Interface Keys: Click Generate to create a key pair.
    • Tunnel Address: e.g., 10.0.0.1/24
  4. Click Save.ivpn.net+1aminrj.com+1docs.netgate.com+6aminrj.com+6mullvad.net+6

Note: The Tunnel Address defines the internal IP range for the VPN tunnel and is used by WireGuard to route traffic between peers.


Step 3: Enable the WireGuard Service

  1. In the WireGuard section, click on the Settings tab.
  2. Check Enable WireGuard.
  3. Click Save and then Apply Changes.

Step 4: Assign the WireGuard Interface

  1. Navigate to Interfaces > Assignments.
  2. Find the newly created WireGuard interface (e.g., tun_wg0) and click Add.
  3. Click on the new interface (e.g., OPT1) to configure it:
    • Enable: Checked
    • Description: e.g., WG_VPN
    • IPv4 Configuration TypeStatic IPv4
    • IPv4 Address: e.g., 10.0.0.1/24
    • MTU1420 (recommended)
  4. Click Save and then Apply Changes.zh.wikipedia.org+4aminrj.com+4docs.netgate.com+4docs.netgate.com+1aminrj.com+1

Clarification: Assigning a static IP ensures consistent routing and firewall rule application, which are crucial for stable VPN operation. WireGuard does not support DHCP for its virtual interfaces.


Step 5: Configure Firewall Rules

Allow WireGuard Traffic on WAN

  1. Navigate to Firewall > Rules > WAN.
  2. Click Add to create a new rule:
    • Action: Pass
    • Protocol: UDP
    • Destination Port Range51820
    • Description: e.g., Allow WireGuard
  3. Click Save and then Apply Changes.forum.netgate.com+2docs.netgate.com+2mullvad.net+2

Allow Traffic from WireGuard Clients

  1. Navigate to Firewall > Rules > [WireGuard Interface] (e.g., WG_VPN).
  2. Click Add to create a new rule:
    • Action: Pass
    • Protocol: Any
    • Source10.0.0.0/24
    • Destination: Any
    • Description: e.g., Allow WireGuard Clients
  3. Click Save and then Apply Changes.

Clarification: The Source refers to the IP addresses assigned to VPN clients within the tunnel network. For instance, if your tunnel network is 10.0.0.0/24, and you’ve assigned 10.0.0.2/32 to a client, you would set the source as 10.0.0.0/24 to encompass all potential client IPs.


Step 6: Add WireGuard Peers (Clients)

For each client device:

  1. Navigate to VPN > WireGuard.
  2. Click Edit on your tunnel.
  3. Scroll to the Peers section and click Add Peer.
  4. Configure the peer:
    • Enable: Checked
    • Description: e.g., Client Device
    • Public Key: Client’s public key
    • Allowed IPs: e.g., 10.0.0.2/32
    • Persistent Keepalive25 (optional, helps with NAT traversal)
  5. Click Save and then Apply Changes.forums.serverbuilds.net

Clarification: The Allowed IPs setting in WireGuard serves dual purposes:

  • Routing: Determines which IP addresses should be routed through the VPN tunnel.
  • Access Control: Specifies which IP addresses a peer is allowed to use.

It’s crucial to assign unique IPs to each peer to prevent routing conflicts.


Step 7: Configure Outbound NAT (if necessary)

If you want WireGuard clients to access the internet through the VPN:

  1. Navigate to Firewall > NAT > Outbound.
  2. Select Manual Outbound NAT rule generation and click Save.
  3. Click Add to create a new rule:
    • Interface: WAN
    • Source10.0.0.0/24
    • Translation AddressInterface Address
  4. Click Save and then Apply Changes.

Step 8: Configure DNS (optional)

To allow VPN clients to resolve DNS:

  1. Navigate to System > General Setup.
  2. Add a DNS server (e.g., 10.0.0.1 if using pfSense as DNS resolver).
  3. Uncheck Allow DNS server list to be overridden by DHCP/PPP on WAN.
  4. Click Save.

Step 9: Configure WireGuard Client (macOS Example)

  1. Download and install the official WireGuard app from the Mac App Store.
  2. Open the WireGuard app on your Mac.
  3. Click the “+” button and select “Add Empty Tunnel”.
  4. The app will generate a new private key and public key.
  5. Assign a unique IP address to your Mac within the VPN tunnel’s subnet (e.g., 10.0.0.2/24).
  6. Set the DNS server to your pfSense router’s LAN IP (e.g., 192.168.1.1) or another preferred DNS server.

Your configuration should look like:

iniCopyEdit[Interface]
PrivateKey = <Your Mac's Private Key>
Address = 10.0.0.2/24
DNS = 192.168.1.1

[Peer]
PublicKey = <pfSense WireGuard Public Key>
Endpoint = <Your pfSense Public IP>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
  • Replace <Your Mac's Private Key> with the private key generated by the app.
  • Replace <pfSense WireGuard Public Key> with the public key from your pfSense WireGuard tunnel configuration.
  • Replace <Your pfSense Public IP> with your pfSense router’s public IP address or dynamic DNS hostname.

Clarification: Each client device should have its own unique peer configuration with distinct keys and IP addresses. Sharing a peer configuration among multiple devices can lead to connection instability and security risks.


Step 10: Test the VPN Connection

  1. Activate the VPN Connection on Your Client Device: Open the WireGuard application on your client device and toggle the switch to activate the VPN tunnel.
  2. Verify the Connection:
    • Check the Status: In the WireGuard app, ensure that the connection status indicates an active tunnel.
    • Ping the pfSense Router: Open a terminal or command prompt on your client device and run:nginxCopyEditping 10.0.0.1 This tests connectivity to the pfSense router’s WireGuard interface.
    • Access Internal Resources: Attempt to access internal network resources, such as shared folders or internal websites, to confirm proper routing.
    • Check Public IP Address: Visit https://whatismyipaddress.com to verify that your public IP address matches your home network’s IP, confirming that internet traffic is routed through the VPN.

Additional Notes and Clarifications

  • One Peer per Client Device: It’s recommended to create a unique peer configuration for each client device. Sharing a peer among multiple devices can lead to connection instability and security concerns.
  • Static IP Assignment: WireGuard operates at Layer 3 and doesn’t support DHCP. Assigning static IP addresses ensures consistent routing and firewall rule application.
  • Allowed IPs Configuration: In the client configuration, setting AllowedIPs = 0.0.0.0/0 routes all traffic through the VPN (full tunnel). To route only specific traffic (split tunnel), specify the desired IP ranges.
  • MTU Settings: The recommended MTU for WireGuard interfaces is 1420 bytes. This accounts for the overhead introduced by encapsulation and ensures optimal performance.en.wikipedia.org
  • DNS Resolution: Ensure that the DNS server specified in the client configuration is accessible through the VPN tunnel. This allows for proper domain name resolution when connected.

Troubleshooting Tips

  • No Internet Access: Verify that outbound NAT rules are correctly configured to allow VPN clients to access the internet.
  • Cannot Access Internal Resources: Ensure that firewall rules on the WireGuard interface permit traffic to the internal network.
  • Connection Drops: Setting PersistentKeepalive = 25 in the client configuration can help maintain the connection, especially when the client is behind NAT.
  • DNS Issues: Confirm that the DNS server specified is reachable and correctly configured to handle queries from VPN clients.

For more detailed information and advanced configurations, refer to the official pfSense documentation: WireGuard on pfSenseforum.netgate.com+8docs.netgate.com+8docs.netgate.com+8

How to Configure RDP when Remotely Connecting to an Entra‑Enrolled Device (Windows 10/11)

How to Configure RDP when Remotely Connecting to an Entra‑Enrolled Device (Windows 10/11)

📌 Overview

These steps describe how to configure Remote Desktop (RDP) to successfully connect to a Microsoft Entra ID (Azure AD) joined device over VPN or office network. This includes editing the .rdp connection file and optionally editing the Windows hosts file on the VPN client to resolve NetBIOS or FQDN names more reliably.

Heavily based on these three articles and built from ticket #2571

Especially useful for Santiam Water Control District staff.

https://learn.microsoft.com/en-us/windows/client-management/client-tools/connect-to-remote-aadj-pc

https://rublon.com/blog/how-to-rdp-into-azure-ad-joined-vm

https://www.howtogeek.com/27350/beginner-geek-how-to-edit-your-hosts-file


✅ Requirements & Prerequisites

  • Remote device: Windows 10 version 1809 or later, or Windows 11 (with Oct‑2022 cumulative update or newer) joined to Microsoft Entra ID. (Microsoft LearnMicrosoft Learn)
  • Local client device: Running Windows 10 or 11. It can be Entra joined, hybrid joined, registered, or even part of a different AD domain. (Microsoft Learn)
  • Ensure the remote device (host) is configured to allow RDP: under Settings → System → Remote Desktop, “Allow Remote Desktop connections” is enabled. (Microsoft Learn)
  • If enabling Azure AD authentication, the remote device doesn’t need Network Level Authentication enforced; indeed disabling NLA may be required for this use case. (Microsoft Learn)

🛠 Step 1 – Edit the .rdp file

  1. On your local client, launch Remote Desktop Connection (mstsc.exe), enter the hostname (NOT the IP Address, often fails in this setup) of the remote device, expand Show Options, and click Save As… to store a .rdp file locally. (Stack Overflow)
  2. Open the saved .rdp file using a text editor like Notepad.
  3. Update the full address:s: field to use the NetBIOS hostname or FQDN, not the IP address. Example:full address:s:Desktop‑Manager (Replaces earlier s: \\192.168.1.119 usage.) (ronamosa.io)
    Your internal ticket notes confirm that Azure AD–joined devices cannot be reached by IP if using Azure AD authentication—they require name resolution.
    enablecredsspsupport:i:0 authentication level:i:2 This disables CredSSP and sets a proper authentication level for Azure AD RDP login. (Stack Overflow)
  4. Additionally, to enable Microsoft Entra (Azure AD) authentication prompt via RDP, add (or change) the following:enablerdsaadauth:i:1 This flag ensures the client uses the web-account sign‑in flow. Without it, authentication via Azure AD may fail. (Microsoft Learn)
  5. Save the file and double-click it to initiate RDP.
  6. At credential prompt, enter your username in full UPN format:username@domain.comYou will be prompted to fully sign in through a popup Microsoft login window and approve this new host; accept it. (RublonMicrosoft Learn)

🧪 Step 2 – (Optional) Add the Azure AD user to the Remote Desktop Users group

If you are not already part of the Remote Desktop Users group on the remote device, you may need to add your account or Azure AD group to it via local admin or MDM policy:

  • Using Command Prompt (as administrator):net localgroup "Remote Desktop Users" /add "AzureAD\username@domain.onmicrosoft.com"
  • Or using PowerShell:Add-LocalGroupMember -Group "Remote Desktop Users" -Member "AzureAD\username@domain.com" (Prajwal Desai)

🧭 Step 3 – (Optional) Edit the hosts file for name resolution over VPN

When your client cannot resolve NetBIOS names over a VPN Connection or Wi‑Fi, you can manually define them:

  1. On the remote client machine, open the hosts file in an elevated editor. Search for Notepad and Run as Administrator > File > Open to the following path:C:\Windows\System32\drivers\etc\hosts
  2. Add entries mapping internal device names to their IP addresses:192.168.1.119 Desktop‑Manager
  3. Save the file. This allows the host name used in your .rdp file to resolve correctly even if DNS or NetBIOS resolution fails.

🧩 Troubleshooting Scenarios & Notes

  • VPN client cannot ping or resolve NetBIOS name: may stem from missing NetBIOS over TCP/IP setting, wireless isolation, subnet differences, or routing rules. Ensure NetBIOS over TCP/IP is enabled in adapter IPv4 → Advanced → WINS tab, and review network isolation settings.
  • RDP fails using IP address: Azure AD joined devices require name (hostname or FQDN). IP‑only connections do not support the Azure AD authentication flow; using a host‑mapped name is required. (Microsoft LearnMicrosoft Learn)
  • NLA required: if NLA is enforced, Azure AD authentication may fail; ensure the remote device has NLA disabled if running into connection issues. (Microsoft Learnniallbrady.comMicrosoft Learn)

✅ Example .rdp snippet

Note: some of these are already added in, so only copy and paste the missing ones and change the relevant entries.

full address:s:Desktop‑Manager
enablecredsspsupport:i:0
authentication level:i:2
enablerdsaadauth:i:1

ℹ️ Why these settings matter

  • enablerdsaadauth:i:1 toggles the web‑account Azure AD login experience, prompting or allowing authentication through Entra ID. Without it, RDP will not negotiate Azure AD credentials correctly. (Microsoft Learn)
  • enablecredsspsupport:i:0 avoids CredSSP pitfalls that block Azure AD authentication, especially when Network Level Authentication isn’t compatible with Entra‑based tokens. (Stack Overflow)
  • authentication level:i:2 is the required setting for secure fallback when CredSSP is disabled. (Stack Overflow)

📌 Final Notes

  • Always ensure both client and remote satisfy Windows update and version prerequisites for Azure AD RDP support. (Microsoft Learn)
  • Use FQDN or hostname resolution rather than IP when targeting Entra‑joined devices, especially in VPN environments.
  • The hosts file edit can be a reliable workaround when DNS or NetBIOS resolution fails.

Help Windows Server 2012 Resolve DNS for Shared PC Hostnames in a Domain

How to Help Windows Server 2012 Resolve DNS for Shared PC Hostnames in a Domain

Raised from ticket #2975

If you are experiencing issues accessing shared computers on your domain, follow these steps to troubleshoot and resolve the problem:

  1. Check Network Discovery: Ensure that network discovery is turned on for the affected computers.
  2. Reboot the Computers: Restart the computers that are having connectivity issues.
  3. Access by IP Address: If you can access the computers by their IP address but not by hostname, this indicates a DNS issue.
  4. Verify DNS Resolution: If you cannot access the computers by hostname and Server 2012 is handling DNS for your domain, check if their IP addresses have changed . You can do this by:
    • Log into the Server
    • Press Win + R to open the Run dialog.
    • Type dnsmgmt.msc and press Enter to open the DNS management console.
    • Navigate to Forward Lookup Zones and select your domain (e.g., AVP.local).
    • Check that the hostname (A Record) matches the correct IP address.
    • NOTE: If you need to add a Hostname, Right Click your Domain Forward Lookup Zone (e.g. AVP.local) and click “Add a New A Record” and enter NetBIOS Hostname and current IP Address
    • On the device handling DHCP, set these hostnames to Static IPs to minimize how often you have to update IP addresses in Server 2012.
  5. Update Hostnames: Consider updating the hostnames in the DNS server to ensure they remain consistent and accessible.

Created by Andrae

© 2026 Ultrex Staff

Theme by Anders NorenUp ↑