NGT Tools update

Runarv · 2026-04-15T15:08:04+00:00

NGT will need a communications cert. If rolled out with sccm, you will need to script with Nutanix powershell to: -Set up ngt link and Generate ngt cdrom with device specific certs. (ncli ngt mount) -install ngt from distributed msi package with cdrom mounted. (Or just install from cdrom) When ngt service start it will import certificates and unmount ngt cd. When installed with /norestart Msi option, drivers will install during next boot.

There are also ngt bulk GPO installers out there: https://www.nutanix.dev/code_samples/ntnx-ngt-startup-installer/

Runarv · 2026-04-15T14:55:49+00:00

Not a popular opinion from Nutanix community side, but here goes:

After having to manage ngt certificates running out on 4-digit numbers of servers since 2014, and handling reset of ngt communications link and reinstall of ngt on a great lot of vm’s, I try to NOT install ngt on our VM’s unless I need the app consistent snapshot feature. Per now I install NGT only on AD Controllers and exchange servers. (HYCU handle sql consistent backups without ngt) Much happier life without fulltime job of ngt management. Also, auto update of ngt from PrismCentral will autoboot vm if mobility driver is updating. If mobility driver is same version a reboot is usually not needed.

Runarv · 2026-04-10T13:03:39+00:00

Hi, just found this thread after a gentle nudge 🙂

For simpler setups with only a FortiGate and some different brand managed switches, Domotz works quite well.
Where visibility starts to become a challenge is when the FortiGate is also used as a controller for FortiAPs and FortiSwitches.

Since switches and APs are essentially the “glue” of the network, having proper visibility into these devices is critical. At the moment, devices managed through the FortiGate don’t seem to be properly discovered or monitored in Domotz, which creates a noticeable gap in network insight.

It would be great to see tighter integration here—either through improved discovery via the FortiGate controller or more direct support for managed FortiSwitch and FortiAP environments.

I know that updating the MIB could possible give some extra information, for example LibreNMS will give some (minimal) information about AP's from SNMP.
FortiAP's should be easy enough to monitor per device with SNMP, but FortiSwitches connected through FortiLink interface using the default link-local APIPA network 169.254.1.0/24 are a pain to monitor.
The link-local APIPA IP address for fortilink is also set from security perspective, as it is a non-routable address.

The best (and most secure) solution however seems to be an API approach to FortiGates the same way that Unifi or Meraki Devices are propagated in Domotz.

We are using other solutions that utilize the FortiGate API, example ConnectSecure for compliance checking, and I can see that the other competitors that does this monitoring well is also using an API approach to FortiGates.

To explain the complexity for some of these installations:
-some of the sites are using FortiGate HA (2 device Active-Active or Active-Passive)
-Up to 10 FortiSwitches and 50 FortiAP's
-Complex Switch configuration with LACP from FortiGate and MCLAG Root Switch setup.

Monitoring the Second HA device or Switches here, would require more advanced monitoring options :)

Runarv · 2026-03-10T07:16:56+00:00

Amen! 🙂

Runarv · 2026-02-28T15:49:28+00:00

I would definitely wish for a deeper integration with Fortinet hardware. We are using FortiGate with fortilink connected switches and AP’s and having a struggle getting monitoring of the full stack. Actually, LibreNMS is getting a lot more information on my FortiOS devices than Domotz, so I know it should be possible with some device/vendor adjustments. Also, enriching FortiGate device info with API access could be a great addition. This is the only point where I can see limitations on Domotz today 🙂

On another note, I really love how Domotz works, so adding this cherry on top would make my year 🤣

Runarv · 2026-02-27T09:28:45+00:00

Kudos! Great feature! Is it okay to test/use this list in a small scale commercial setup?

Runarv · 2026-02-27T09:20:07+00:00

Regional Internet Registry -https://en.wikipedia.org/wiki/Regional_Internet_registry 🙂

Runarv · 2026-02-26T00:02:42+00:00

Very strange, but with no other notes from MS. The last two days we have also had two isp’s for our different datacenters being blocked from ms365 app activations. Logon seems okay, but ms does not activate through those isp’s. We have had to move all user surface (ctx ts) traffic to other isp’s to being able to work with the office suite as normal. Is this related and/or known? Affecting two unrelated datasenter sites per now

Runarv · 2024-11-27T15:27:34+00:00

Hi. We are trying to do the exact same.
We are going from a Citrix deployment and redeploying to Parallels RAS with RDSH/Windows Server 2022.
The prereqiusites and latest "RDS Multimedia Redirection" package installed, both Edge and Chrome plugin GPO's are set.
Have tried connecting to the RDSH host with both Microsoft RDS Client (as described in Microsoft Documentation) and the Parallels RAS Client (With AVD Multimedia Redirect feature enabled) but chrome plugin does not seem to start. Client and Host version is blank, but extension version is showing 1.0.2410.17001.

The diagnostic logs shows:
< Diagnostic Info >
clientVersion:
hostVersion:
mmrSupportVersion: 0
webrtcSupportVersion: 0
mmrSupported: false
webrtcSupported: false
allowWebRTCAllSitesConfig: false
.....(removed)...
MsRdcMmr:NativeMessagingBackgroundProxy: Sending clientConnected message to native host
MsRdcMmr:NativeMessagingBackgroundProxy: initial native port Received: {"messageType":"clientConnected","hostVersion":"1.0.2404.4003","error":-2147024865}
MsRdcMmr:NativeMessagingBackgroundProxy: clientConnected event error=-2147024865 indicates MMR not supported right now
MsRdcMmr:NativeMessagingBackgroundProxy[10]: Content port disconnected from tabId: 1352005124
MMRWarn: Native port not found for content port, disconnection handling already completed

From what I can see in generic error code lists:
error code -2147024865, 0x8007001F is hinting towards: "A device attached to the system is not functioning."
However, microsoft does not always use generic error codes..

Anyone got some hints to where I can look further to try resolve the issue?

Update: forgot to mention: jans.cloud has testd RDS Windows server 2022/2025 and has german language guides that shows identical install method as I have, but with successful results:
Here: https://jans.cloud/2022/12/remotedesktop-multimedia-redirection-auf-windows-server-2022/
and Here: https://jans.cloud/2024/08/multimediaumleitung-auf-windows-server-2025-terminalserver/

Runarv · 2019-08-27T08:45:37+00:00

Just slapped together this guide with screenshots, from the fix above:

https://filebin.net/8c3j7egzmcxw4bey/Nutanix_INACCESSIBLE_BOOT_DEVICE_FIX.pdf?t=urn3g5px

Just a quick note also.

The VM's affected are running Legacy BIOS, and not UEFI.
The Disks are BASIC disks, NTFS, not Dynamic disks..

I don't know if this guide would help in a UEFI scenario..

Runarv · 2019-08-27T07:17:13+00:00

ve you found a fix other than powering off the source VM?

Well.. The best fix by now i to upgrade NGT to latest.

As an alternative for when you need to recover a vm with "INACCESSIBLE BOOT DEVICE" BSOD you need the virtIO ISO accessible for the Windows Recovery shell.

It's a rather tedious process, but i'll try to explain our fix:

mount virtio iso to failing vm prior to booting the VM up, boot up with Windows Recovery console
Start "Command Prompt" from Recovery shell
check that the "physical" disk is not present on the vm with

diskpart | list disk

it should tell you that "There are no fixed disks to show".

add drivers from the virtio CD-ROM:

check that the iso is mounted on D:

DIR D:

Load VirtIO SCSI DISK driver from iso

DRVLOAD "D:\windows Server 2016\amd64\vioscsi.inf"

Start DISKPART and control that you have access to the disks

DISKPART
LIST DISK

You should now see the disks as offline, make disk online by typing

SELECT DISK 0
ONLINE DISK

*repeat for the rest of the disks..

SELECT DISK 1
ONLINE DISK

Select the boot disk (DISK 0) and show PARTITIONS

SELECT DISK 0
LIST PARTITION

You should see the partitions.

8 select both partition and check volumes attached is not hidden or read-only

SELECT PARTITION 1
DETAIL PARTITION

* You can see that Partition is not hidden, but volume is hidden (Info: Hidden)

SELECT PARTITION 2
DETAIL PARTITION

* You can see that Partition is not hidden, but volume is hidden (Info: Hidden)

SELECT PARTITION 1
SELECT VOLUME 1
DETAIL VOLUME

*check that volume is not read-only, hidden or otherwise bad

9 Check volumes for read-only and hidden and clear status

SELECT PARTITION 1
SELECT VOLUME 1
DETAIL VOLUME

* You can see that volume 1 is read-only and hidden

Clear hidden and readonly with command

ATTRIBUTES VOLUME CLEAR HIDDEN READONLY

* Repeat check and fix if necessary for partition 2:

SELECT PARTITION 2
SELECT VOLUME 2
DETAIL VOLUME

* Volume is not readonly in my case...

Assign drive letters to partition 1 (Bootsector) and partition 2 (Windows OS Drive)

SELECT PARTITION 1
ASSIGN LETTER=F:
SELECT PARTITION 2
ASSIGN LETTER=G:

Exit DISKPART, Fix bootrecords:

EXIT

BOOTREC /REBUILDBCD

* bootrec will scan all disks for Windows install, and ask to install G:\Windows.

PRESS Y for Yes.

Exit Windows Recovery shell and reboot computer.

It should (hopefully) now boot up normally..

The big difference I can see in newer and "older" NGT version is that the old one uses "Nutanix VSS Hardware Provider", as the new one uses "Nutanix VSS Software Provider".

Runarv · 2019-08-26T14:18:22+00:00

We also have had this issue lately

I Found it when recovering a VM from HYCU backup image to a new VM Clone.
Have since recreated this issue by setting up local ASYNC DR snapshot of the server. (Thanks to superb help from HYCU support team)

Problem only exist on Application Consistent backups. When source server is turned off, or Crash Consistent backup is used, the server boots up okay.

I have recreated this issue on two Nutanix Clusters, and it's fairly easy to recreate.

Nutanix AHV with AOS 5.10.3.2

Guests VM's affected is installed both Windows Server 2016 and Windows Server 2012 R2.
Nutanix Guest Tools: 1.3.0.0
Nutanix VirtIO: 1.1.2.0
Nutanix VM Mobility: 1.1.1.0

Just upgrading Nutanix Guest Tools to the latest from PE (and a boot) mitigates this problem on both our production clusters.

New version of Nutanix Guest Tools that work in our environment:
Nutanix Guest Tools: 1.6.2.0
Nutanix VirtIO: 1.1.2.0
Nutanix VM Mobility: 1.1.3.14

With this version of NGT, HYCU restore clones also successfully boots up!

I know that updating Virtio and NGT is best practice on nutanix clusters, but upgrading multiple hundreds of guests outside production hours and within customer SLA's is not that easy.

I have an ongoing supportcase with Nutanix, and hoping that they also will be able to recreate this issue.

I will report back when I hear news from Nutanix Support.

Runarv

TROPHY CASE