Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Domain and FQDN not picked-up correctly on Windows Server 2016 #1274

Open
karim-jaouadi opened this issue Oct 16, 2018 · 6 comments
Open

Domain and FQDN not picked-up correctly on Windows Server 2016 #1274

karim-jaouadi opened this issue Oct 16, 2018 · 6 comments
Assignees
Labels
Focus: Desktop Issues that impact the Chef Desktop offering

Comments

@karim-jaouadi
Copy link

karim-jaouadi commented Oct 16, 2018

Internal issue CHEF-607 ... might relate to #1733

Description

Ohai don't seem to pick-up and update the attributes related to domain and FQDN correctly on Windows Server 2016.
The below output is what I see from Chef Manage standpoint. On the server I can see the domain and FQDN as the server joined the Active Directory. I've try to run another time to see if it change a thing but no success.

machinename: 123401XYZW007
domain:
hostname: 123401XYZW007
fqdn: 123401XYZW007

Looking at the code it seems that the way of collecting those information don't seems supported on Windows Server 2016 (See below). I've provided suggested way to read those value (tested from Powershell) it that could be validated and implemented.

Ohai Version

PS C:\Windows\system32> ohai --version
Ohai: 14.5.5

Platform Version

Windows Server 2016

Output of current Ohai call

Base on the code below

collect_data(:windows) do
require "wmi-lite/wmi"
require "socket"
wmi = WmiLite::Wmi.new
host = wmi.first_of("Win32_ComputerSystem")
hostname host["dnshostname"].to_s
machinename host["name"].to_s
info = Socket.gethostbyname(Socket.gethostname)
if info.first =~ /.+?\.(.*)/
fqdn info.first
else
# host is not in dns. optionally use:
# C:\WINDOWS\system32\drivers\etc\hosts
fqdn Socket.gethostbyaddr(info.last).first
end
domain collect_domain
end

The powershell instruction are not recognized.

PS C:\Windows\system32> Socket.gethostbyname(Socket.gethostname)
Socket.gethostname : The term 'Socket.gethostname' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the 
name, or if a path was included, verify that the path is correct and try again.
At line:1 char:22
+ Socket.gethostbyname(Socket.gethostname)
    + CategoryInfo          : ObjectNotFound: (Socket.gethostname:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException
 

PS C:\Windows\system32> Socket.gethostname
Socket.gethostname : The term 'Socket.gethostname' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the 
name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ Socket.gethostname
    + CategoryInfo          : ObjectNotFound: (Socket.gethostname:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Suggested method to call

Seems the following methods are supported out of the box and provide either machine_name and domain or the FQDN.

$myFQDN=(Get-WmiObject win32_computersystem).DNSHostName+"."+(Get-WmiObject win32_computersystem).Domain
Write-Host $myFQDN
[System.Net.Dns]::GetHostByName($env:computerName).HostName
[System.Net.Dns]::GetHostByName((hostname)).HostName
@tas50
Copy link
Contributor

tas50 commented Nov 28, 2018

@karim-jaouadi We have a fix that may resolve this that was just merged into master and will ship in Ohai 14.8

@Ryuzavi
Copy link

Ryuzavi commented Jan 9, 2019

Hey. FWIW I'm still seeing the FQDN resolution failure on Windows Server 2019 with ohai version 14.8.10.

@stellarsquall
Copy link

stellarsquall commented Apr 24, 2019

I'm noticing this as well, the hint always returns empty values on Windows 2016.

It's supposed to gather this from the metadata available at http://169.254.169.254/latest/meta-data, but this doesn't work out of the box. There's a script here that fixes the issue:

https://forums.aws.amazon.com/thread.jspa?messageID=790984

Add-Content 'c:\script.log' (date)
 
# This fixes a bug in AWS startup script processing.
 
# 169.254.169.254 is for metadata service
# 169.254.169.250 is for KmsInstanceVpc1
# 169.254.169.251 is for KmsInstanceVpc2
$ipAddrs = @("169.254.169.254/32", "169.254.169.250/32", "169.254.169.251/32")
 
$sleepTime = 1
$count = 0
 
# Retry logic for querying primary network interface and adding routes.
while($true)
{
    try
    {
        Add-Content 'c:\script.log' "Checking primary network interface"
 
        $ipConfigs = Get-NetIPConfiguration | Sort-Object -Property "InterfaceIndex" | select InterfaceIndex, IPv4DefaultGateway
        if(-not $ipConfigs -or $ipConfigs.Length -eq 0)
        {
            throw New-Object System.Exception("Failed to find the primary network interface")
        }
        $primaryIpConfig = $ipConfigs[0]
        $interfaceIndex = $primaryIpConfig.InterfaceIndex
        $defaultGateway = $primaryIpConfig.IPv4DefaultGateway.NextHop
        $interfaceMetric = 1
 
        Add-Content 'c:\script.log' "Primary network interface found. Adding routes now..."
 
        foreach ($ipAddr in $ipAddrs)
        {
            try
            {
                Remove-NetRoute -DestinationPrefix $ipAddr -PolicyStore ActiveStore -Confirm:$false -ErrorAction SilentlyContinue
                Remove-NetRoute -DestinationPrefix $ipAddr -PolicyStore PersistentStore -Confirm:$false -ErrorAction SilentlyContinue
                New-NetRoute -DestinationPrefix $ipAddr -InterfaceIndex $interfaceIndex `
                    -NextHop $defaultGateway -RouteMetric $interfaceMetric -ErrorAction Stop
                Add-Content 'c:\script.log' ("Successfully added the Route: {0}, gateway: {1}, NIC index: {2}, Metric: {3}" `
                    -f $ipAddr, $defaultGateway, $interfaceIndex, $interfaceMetric)
            }
            catch
            {
                Add-Content 'c:\script.log' ("Failed to add routes: {0}" -f $ipAddr)
            }
        }
 
        # Break if routes are added successfully.
        break
    }
    catch
    {
        Add-Content 'c:\script.log' ("Failed to add routes.. attempting it again {0}" -f $_.Exception.Message)
    }
 
    # It logs the status every 2 minutes.
    if (($count * $sleepTime) % 120 -eq 0)
    {
        Add-Content 'c:\script.log' "Message: Failed to add routes.. attempting it again"
    }
 
    Start-Sleep -seconds $sleepTime
    $count ++
}

@Nimesh-Msys
Copy link
Contributor

Updated code is available in Ohai version 15.0.13.
chef-client: 14.12.9 that I installed with MSI is using Ohai-14.8.11

@Nimesh-Msys
Copy link
Contributor

Additionally, To get the FQDN in powershell, we could try

$a = [System.Net.Dns]::GetHostByName(($env:computerName))
$hostName = [System.Net.Dns]::GetHostByAddress($a.AddressList.IpAddressToString)
$hostName.HostName

@tas50 tas50 added the Focus: Desktop Issues that impact the Chef Desktop offering label Aug 3, 2021
@affieuk
Copy link

affieuk commented Aug 26, 2021

The PowerShell equivalent of:

info = Socket.gethostbyname(Socket.gethostname)
...
  fqdn info.first`

Is:
[System.Net.Dns]::GetHostByName([System.Net.Dns]::GetHostName()).HostName

@tpowell-progress tpowell-progress self-assigned this Aug 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Focus: Desktop Issues that impact the Chef Desktop offering
Projects
None yet
Development

No branches or pull requests

7 participants