device assignment

The “Hey, Scripting Guys!” blog has been retired. There are many useful posts in this blog, so we keep the blog here for historical reference. However, some information might be very outdated and many of the links might not work anymore.

New PowerShell content is being posted to the PowerShell Community blog where members of the community can create posts by submitting content in the GitHub repository .

Passing through devices to Hyper-V VMs by using discrete device assignment

Doctor Scripto

July 14th, 2016 2 0

Summary : Learn how to attach a device from your Hyper-V host to your VM by using a new feature of Windows Server 2016.

Today we have a guest blogger, Rudolf Vesely, who has blogged here on previous occasions. Here is a link to his previous posts if you would like to read them.

Here is what Rudolf says about himself.

I am an Azure Solutions Architect at Rackspace in London. I believe that public cloud is the future for most organizations and this is why I specialize in public clouds (Amazon Web Services and Azure) and hybrid cloud strategy. My unique role at Rackspace is to guide our customers in their cloud strategy and ensure that their strategy is aligned with their business.

I started my career as a developer and have continued programming and scripting as a hobby. This is the reason why I am a big proponent of DevOps. I believe PowerShell is a fantastic tool that facilitates the process of joining the Dev and Ops worlds.

Contact information:

Twitter: @rudolfvesely
Blog: Technology Stronghold

Introduction

Many new features in Windows Server 2016 (in any Technical Preview) will draw your attention, and it’s very easy to miss some of them. This is true especially when people don’t speak or blog about them too much like they do for Windows PowerShell 5.0, Storage Spaces Direct, or Storage Replica, as examples.

One feature that drew my attention is a new feature in Hyper-V called discrete device assignment. It can be very simply described as a device pass-through feature, the likes of which has existed on other hypervisors for many years.

Microsoft started with device pass-through on Hyper-V with disk pass-through (attaching a physical disk without using VHD / VHDX), but true pass-through came with single root I/O virtualization (SR-IOV) on Windows Server 2012. I recommend that you read John Howard’s excellent blog post series that describes SR-IOV and hardware and system requirements .

On Windows Server 2016, we finally get the ability to directly work with devices on the host and attach them to a child partition (guest VM) without being limited to only networking and storage. This feature was probably built for passing-through graphics processing units (GPUs) in Azure for N-series VMs (GPU-enabled VMs), but we can use it for anything else. Please keep in mind that this is at your own risk. Microsoft will not support your setups, and you may also have very hard security issues. Any device pass-through on any hypervisor opens the possibility to take down the host (for example, by triggering an error on the PCI Express bus) or worse, taking control of your host.

The last thing you need to consider is whether you have hardware to test on it. You need a modern client computer or server that has Intel Virtualization Technology for Directed I/O (VT-d) or AMD Virtualization (AMD-V). I use an industrial mini PC, which will be my new router and wireless access point (all virtualized), but you should be fine with a modern laptop. So, if you’re still reading, activate Intel VT-d in firmware of your testing computer, install the latest Technical Preview of Windows Server 2016, and start with PnpDevice.

PnpDevice module

On Windows Server 2016, thanks to the PnpDevice module, we finally have the possibility to work with hardware without directly touching Windows Management Instrumentation (WMI). The PnpDevice module will be very important for Nano Server and non-GUI servers, so I recommend that you try it.

Get-Command -Module PnpDevice

CommandType Name Version Source

----------- ---- ------- ------

Function Disable-PnpDevice 1.0.0.0 PnpDevice Function Enable-PnpDevice 1.0.0.0 PnpDevice Function Get-PnpDevice 1.0.0.0 PnpDevice Function Get-PnpDeviceProperty 1.0.0.0 PnpDevice

Let’s take a look what is attached to your system by using:

Get-PnpDevice –PresentOnly | Sort-Object –Property Class

Screenshot of devices attached to the system.

A lot of devices were returned. Now it’s a good idea to choose what should be passed. I do not have multiple GPUs to pass it, but my goal is to virtualize my router and access point, and I have two wireless adapters in mini PCI-e slots. I found that the easiest way to find them is by using vendor ID:

(Get-PnpDevice -PresentOnly).Where{ $_.InstanceId -like '*VEN_168C*' } # 168C == Qualcomm Atheros

Screenshot of result by using the vendor ID.

If you installed drivers on your host for devices that you want to pass through (I did not), you can filter according to Class Net like this (example from my Surface Book):

I will assume that you have installed the VM and chosen a device to attach to it. I installed Windows 10 version 1511 because this is the easiest method to test that dual dynamic acceleration (DDA) works. Later I will try replacing Windows with virtualized pfSense (FreeBSD appliance) and DD-WRT (Linux appliance). Especially in FreeBSD, I might have problems with drivers, and I am sure that I will have no issues with drivers in Windows 10.

Let’s get VM object and device object of my Wi-Fi adapter:

$vmName = 'VMDDA1' $instanceId = '*VEN_168C&DEV_002B*'

$vm = Get-VM -Name $vmName $dev = (Get-PnpDevice -PresentOnly).Where{ $_.InstanceId -like $instanceId }

Our first action should be to disable the device. You can check Device Manager by typing devmgmt.msc in the PowerShell console to see that the correct device was disabled.

# Make sure that your console or integrated scripting environment (ISE) runs in elevated mode Disable-PnpDevice -InstanceId $dev.InstanceId -Confirm:$false

Screenshot that shows disabled device in Device Manager.

Now we need to dismount the device from the host by using the Dismount-VmHostAssignableDevice cmdlet. To specify a location of the device, we need to get a specific property that is not presented in the device object by using Get-PnpDeviceProperty .

locationPath = (Get-PnpDeviceProperty -KeyName DEVPKEY_Device_LocationPaths -InstanceId $dev.InstanceId).Data[0] Dismount-VmHostAssignableDevice -LocationPath $locationPath -Force –Verbose

Now if you refresh the device object, you can see that something changed: Device is described as “Dismounted”:

(Get-PnpDevice -PresentOnly).Where{ $_.InstanceId -like $instanceId }

You can check available assignable devices by using Get-VMHostAssignableDevice :

Screenshot that shows available assignable devices.

The last step is to attach an assignable device to the VM by using Add-VMAssignableDevice like this:

Add-VMAssignableDevice -VM $vm -LocationPath $locationPath –Verbose

You may get error like this one:

This is because you haven’t modified the VM configuration after you created it. There are two main requirements for passing through. The first is that the VM has to have Automatic Stop Action set to Turn off the virtual machine . This will probably be the only VM on your host that has this configuration because we usually want Shut down or Save . The second requirement is memory configuration. Dynamic memory is allowed, but minimum and startup memory have to be equal. Let’s fix it, and finally attach our device.

Set-VM -VM $vm -DynamicMemory -MemoryMinimumBytes 1024MB -MemoryMaximumBytes 4096MB -MemoryStartupBytes 1024MB -AutomaticStopAction TurnOff Add-VMAssignableDevice -VM $vm -LocationPath $locationPath –Verbose

Screenshot that shows AutomaticStopAction is set to TurnOff and memory is configured.

If you spend some time playing with DDA, you can finish, for example, with multiple Wi-Fi adapters and one physical like I did (all functional):

Screenshot that shows multiple Wi-Fi adapters and one physical adapter.

Restore configuration

That was fun! Now it’s time to return devices to the host.

# Remove all devices from a single VM Remove-VMAssignableDevice -VMName VMDDA0 -Verbose

# Return all to host Get-VMHostAssignableDevice | Mount-VmHostAssignableDevice -Verbose

# Enable it in devmgmt.msc (Get-PnpDevice -PresentOnly).Where{ $_.InstanceId -match 'VEN_168C&DEV_002B' } | Enable-PnpDevice -Confirm:$false -Verbose

$vmName = 'VMDDA0' $instanceId = '*VEN_168C&DEV_002B*' $ErrorActionPreference = 'Stop' $vm = Get-VM -Name $vmName $dev = (Get-PnpDevice -PresentOnly).Where{ $_.InstanceId -like $instanceId } if (@($dev).Count -eq 1) {

Disable-PnpDevice -InstanceId $dev.InstanceId -Confirm:$false $locationPath = (Get-PnpDeviceProperty -KeyName DEVPKEY_Device_LocationPaths -InstanceId $dev.InstanceId).Data[0] Dismount-VmHostAssignableDevice -LocationPath $locationPath -Force -Verbose Set-VM -VM $vm -DynamicMemory -MemoryMinimumBytes 1024MB -MemoryMaximumBytes 4096MB -MemoryStartupBytes 1024MB -AutomaticStopAction TurnOff

# If you want to play with GPUs: # Set-VM -VM $vm -StaticMemory -MemoryStartupBytes 4096MB -AutomaticStopAction TurnOff # Set-VM -VM $vm -GuestControlledCacheTypes $true -LowMemoryMappedIoSpace 2048MB -HighMemoryMappedIoSpace 4096MB -Verbose

Add-VMAssignableDevice -VM $vm -LocationPath $locationPath -Verbose

$dev | Sort-Object -Property Class | Format-Table -AutoSize Write-Error -Message ('Number of devices: {0}' -f @($dev).Count)

Thank you for reading, and see you in the next article.

Thank you, Rudolf, for sharing your time and knowledge.

I invite you to follow me on Twitter and Facebook . If you have any questions, send email to me at [email protected] , or post your questions on the Official Scripting Guys Forum . Also check out my Microsoft Operations Management Suite Blog . See you tomorrow. Until then, peace.

Ed Wilson , Microsoft Scripting Guy

Doctor Scripto Scripter, PowerShell, vbScript, BAT, CMD

Discussion is closed. Login to edit/delete existing comments.

In the mount sub-section, $locationPath variable is missing $ sign.

I had some problems and it took me hours to find a solution. So I want to share it. Dismounting the device from the host worked once, but I forgot to remove my VM from a cluster… So I had to undo my actions and start again and ended in “ The required virtualization driver (pcip.sys) failed to load. ” Anyway here ist the solution: You have to delete the device from the registry yourself. 1. “ psexec -s -i regedit.exe ” 2. You find your device as “Dismounted” under “ HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\PCIP ” e.g. “PCI Express Graphics Processing Unit – Dismounted” 3. Delete the whole key with subkeys under PCIP. 4. Reboot and you can unmount it again from the host 🙂

Working Hard In IT

My view on it from the trenches.

Setting up Discrete Device Assignment with a GPU

Introduction.

Let’s take a look at setting up Discrete Device Assignment with a GPU. Windows Server 2016 introduces Discrete Device Assignment (DDA). This allows a PCI Express connected device, that supports this, to be connected directly through to a virtual machine.

The idea behind this is to gain extra performance. In our case we’ll use one of the four display adapters in our NVIDIA GROD K1 to assign to a VM via DDA. The 3 other can remain for use with RemoteFX. Perhaps we could even leverage DDA for GPUs that do not support RemoteFX to be used directly by a VM, we’ll see.

As we directly assign the hardware to VM we need to install the drivers for that hardware inside of that VM just like you need to do with real hardware.

I refer you to the starting blog of a series on DDA in Windows 2016:

Discrete Device Assignment — Guests and Linux

Here you can get a wealth of extra information. My experimentations with this feature relied heavily on these blogs and MSFT provide GitHub script to query a host for DDA capable devices. That was very educational in regards to finding out the PowerShell we needed to get DDA to work! Please see A 1st look at Discrete Device Assignment in Hyper-V to see the output of this script and how we identified that our NVIDIA GRID K1 card was a DDA capable candidate.

Requirements

There are some conditions the host system needs to meet to even be able to use DDA. The host needs to support Access Control services which enables pass through of PCI Express devices in a secure manner. The host also need to support SLAT and Intel VT-d2 or AMD I/O MMU. This is dependent on UEFI, which is not a big issue. All my W2K12R2 cluster nodes & member servers run UEFI already anyway. All in all, these requirements are covered by modern hardware. The hardware you buy today for Windows Server 2012 R2 meets those requirements when you buy decent enterprise grade hardware such as the DELL PowerEdge R730 series. That’s the model I had available to test with. Nothing about these requirements is shocking or unusual.

A PCI express device that is used for DDA cannot be used by the host in any way. You’ll see we actually dismount it form the host. It also cannot be shared amongst VMs. It’s used exclusively by the VM it’s assigned to. As you can imagine this is not a scenario for live migration and VM mobility. This is a major difference between DDA and SR-IOV or virtual fibre channel where live migration is supported in very creative, different ways. Now I’m not saying Microsoft will never be able to combine DDA with live migration, but to the best of my knowledge it’s not available today.

The host requirements are also listed here: https://technet.microsoft.com/en-us/library/mt608570.aspx

The processor must have either Intel’s Extended Page Table (EPT) or AMD’s Nested Page Table (NPT).

The chipset must have:

The firmware tables must expose the I/O MMU to the Windows hypervisor. Note that this feature might be turned off in the UEFI or BIOS. For instructions, see the hardware documentation or contact your hardware manufacturer.

You get this technology both on premises with Windows Server 2016 as and with virtual machines running Windows Server 2016; Windows 10 (1511 or higher) and Linux distros that support it. It’s also an offering on high end Azure VMs (IAAS). It supports both Generation 1 and generation 2 virtual machines. All be it that generation 2 is X64 bit only, this might be important for certain client VMs. We’ve dumped 32 bit Operating systems over decade ago so to me this is a non-issue.

For this article I used a DELL PowerEdge R730, a NVIIA GRID K1 GPU. Windows Server 2016 TPv4 with CU of March 2016 and Windows 10 Insider Build 14295.

Microsoft supports 2 devices at the moment:

NVMe (Non-Volatile Memory express) SSD controllers

Other devices might work but you’re dependent on the hardware vendor for support. Maybe that’s OK for you, maybe it’s not.

Below I describe the steps to get DDA working. There’s also a rough video out on my Vimeo channel: Discrete Device Assignment with a GPU in Windows 2016 TPv4 .

Preparing a Hyper-V host with a GPU for Discrete Device Assignment

First of all, you need a Windows Server 2016 Host running Hyper-V. It needs to meet the hardware specifications discussed above, boot form EUFI with VT-d enabled and you need a PCI Express GPU to work with that can be used for discrete device assignment.

It pays to get the most recent GPU driver installed and for our NVIDIA GRID K1 which was 362.13 at the time of writing.

On the host when your installation of the GPU and drivers is OK you’ll see 4 NIVIDIA GRID K1 Display Adapters in device manager.

We create a generation 2 VM for this demo. In case you recuperate a VM that already has a RemoteFX adapter in use, remove it. You want a VM that only has a Microsoft Hyper-V Video Adapter.

In Hyper-V manager I also exclude the NVDIA GRID K1 GPU I’ll configure for DDA from being used by RemoteFX. In this show case that we’ll use the first one.

OK, we’re all set to start with our DDA setup for an NVIDIA GRID K1 GPU!

Assign the PCI Express GPU to the VM

Prepping the gpu and host.

As stated above to have a GPU assigned to a VM we must make sure that the host no longer has use of it. We do this by dismounting the display adapter which renders it unavailable to the host. Once that is don we can assign that device to a VM.

Let’s walk through this. Tip: run PoSh or the ISE as an administrator.

We run Get-VMHostAssignableDevice. This return nothing as no devices yet have been made available for DDA.

I now want to find my display adapters

#Grab all the GPUs in the Hyper-V Host

$MyDisplays = Get-PnpDevice | Where-Object {$_.Class -eq “Display”}

$MyDisplays | ft -AutoSize

This returns

As you can see it list all adapters. Let’s limit this to the NVIDIA ones alone.

#We can get all NVIDIA cards in the host by querying for the nvlddmkm

#service which is a NVIDIA kernel mode driver

$MyNVIDIA = Get-PnpDevice | Where-Object {$_.Class -eq “Display”} |

Where-Object {$_.Service -eq “nvlddmkm”}

$MyNVIDIA | ft -AutoSize

If you have multiple type of NVIDIA cared you might also want to filter those out based on the friendly name. In our case with only one GPU this doesn’t filter anything. What we really want to do is excluded any display adapter that has already been dismounted. For that we use the -PresentOnly parameter.

#We actually only need the NVIDIA GRID K1 cards, let’s filter some #more,there might be other NVDIA GPUs.We might already have dismounted #some of those GPU before. For this exercise we want to work with the #ones that are mountedt he paramater -PresentOnly will do just that.

$MyNVidiaGRIDK1 = Get-PnpDevice -PresentOnly| Where-Object {$_.Class -eq “Display”} |

Where-Object {$_.Service -eq “nvlddmkm”} |

Where-Object {$_.FriendlyName -eq “NVIDIA Grid K1”}

$MyNVidiaGRIDK1 | ft -AutoSize

Extra info: When you have already used one of the display adapters for DDA (Status “UnKnown”). Like in the screenshot below.

We can filter out any already unmounted device by using the -PresentOnly parameter. As we could have more NVIDIA adaptors in the host, potentially different models, we’ll filter that out with the FriendlyName so we only get the NVIDIA GRID K1 display adapters.

In the example above you see 3 display adapters as 1 of the 4 on the GPU is already dismounted. The “Unkown” one isn’t returned anymore.

Anyway, when we run

We get an array with the display adapters relevant to us. I’ll use the first (which I excluded form use with RemoteFX). In a zero based array this means I disable that display adapter as follows:

Disable-PnpDevice -InstanceId $MyNVidiaGRIDK1[0].InstanceId -Confirm:$false

When you now run

Again you’ll see

The disabled adapter has error as a status. This is the one we will dismount so that the host no longer has access to it. The array is zero based we grab the data about that display adapter.

#Grab the data (multi string value) for the display adapater

$DataOfGPUToDDismount = Get-PnpDeviceProperty DEVPKEY_Device_LocationPaths -InstanceId $MyNVidiaGRIDK1[0].InstanceId

$DataOfGPUToDDismount | ft -AutoSize

We grab the location path out of that data (it’s the first value, zero based, in the multi string value).

#Grab the location path out of the data (it’s the first value, zero based)

#How do I know: read the MSFT blogs and read the script by MSFT I mentioned earlier.

$locationpath = ($DataOfGPUToDDismount).data[0]

$locationpath | ft -AutoSize

This locationpath is what we need to dismount the display adapter.

#Use this location path to dismount the display adapter

Dismount-VmHostAssignableDevice -locationpath $locationpath -force

Once you dismount a display adapter it becomes available for DDA. When we now run

As you can see the dismounted display adapter is no longer present in display adapters when filtering with -presentonly. It’s also gone in device manager.

Yes, it’s gone in device manager. There’s only 3 NVIDIA GRID K1 adaptors left. Do note that the device is unmounted and as such unavailable to the host but it is still functional and can be assigned to a VM.That device is still fully functional. The remaining NVIDIA GRID K1 adapters can still be used with RemoteFX for VMs.

It’s not “lost” however. When we adapt our query to find the system devices that have dismounted I the Friendly name we can still get to it (needed to restore the GPU to the host when needed). This means that -PresentOnly for system has a different outcome depending on the class. It’s no longer available in the display class, but it is in the system class.

And we can also see it in System devices node in Device Manager where is labeled as “PCI Express Graphics Processing Unit – Dismounted”.

We now run Get-VMHostAssignableDevice again see that our dismounted adapter has become available to be assigned via DDA.

This means we are ready to assign the display adapter exclusively to our Windows 10 VM.

Assigning a GPU to a VM via DDA

You need to shut down the VM

Change the automatic stop action for the VM to “turn off”

This is mandatory our you can’t assign hardware via DDA. It will throw an error if you forget this.

I also set my VM configuration as described in https://blogs.technet.microsoft.com/virtualization/2015/11/23/discrete-device-assignment-gpus/

I give it up to 4GB of memory as that’s what this NVIDIA model seems to support. According to the blog the GPUs work better (or only work) if you set -GuestControlledCacheTypes to true.

“GPUs tend to work a lot faster if the processor can run in a mode where bits in video memory can be held in the processor’s cache for a while before they are written to memory, waiting for other writes to the same memory. This is called “write-combining.” In general, this isn’t enabled in Hyper-V VMs. If you want your GPU to work, you’ll probably need to enable it”

#Let’s set the memory resources on our generation 2 VM for the GPU

Set-VM RFX-WIN10ENT -GuestControlledCacheTypes $True -LowMemoryMappedIoSpace 2000MB -HighMemoryMappedIoSpace 4000MB

You can query these values with Get-VM RFX-WIN10ENT | fl *

We now assign the display adapter to the VM using that same $locationpath

Add-VMAssignableDevice -LocationPath $locationpath -VMName RFX-WIN10ENT

Boot the VM, login and go to device manager.

We now need to install the device driver for our NVIDIA GRID K1 GPU, basically the one we used on the host.

Once that’s done we can see our NVIDIA GRID K1 in the guest VM. Cool!

You’ll need a restart of the VM in relation to the hardware change. And the result after all that hard work is very nice graphical experience compared to RemoteFX

What you don’t believe it’s using an NVIDIA GPU inside of a VM? Open up perfmon in the guest VM and add counters, you’ll find the NVIDIA GPU one and see you have a GRID K1 in there.

Start some GP intensive process and see those counters rise.

Remove a GPU from the VM & return it to the host.

When you no longer need a GPU for DDA to a VM you can reverse the process to remove it from the VM and return it to the host.

Shut down the VM guest OS that’s currently using the NVIDIA GPU graphics adapter.

In an elevated PowerShell prompt or ISE we grab the locationpath for the dismounted display adapter as follows

$DisMountedDevice = Get-PnpDevice -PresentOnly |

Where-Object {$_.Class -eq “System” -AND $_.FriendlyName -like “PCI Express Graphics Processing Unit – Dismounted”}

$DisMountedDevice | ft -AutoSize

We only have one GPU that’s dismounted so that’s easy. When there are more display adapters unmounted this can be a bit more confusing. Some documentation might be in order to make sure you use the correct one.

We then grab the locationpath for this device, which is at location 0 as is an array with one entry (zero based). So in this case we could even leave out the index.

$LocationPathOfDismountedDA = ($DisMountedDevice[0] | Get-PnpDeviceProperty DEVPKEY_Device_LocationPaths).data[0]

$LocationPathOfDismountedDA

Using that locationpath we remove the DDA GPU from the VM

#Remove the display adapter from the VM.

Remove-VMAssignableDevice -LocationPath $LocationPathOfDismountedDA -VMName RFX-WIN10ENT

We now mount the display adapter on the host using that same locationpath

#Mount the display adapter again.

Mount-VmHostAssignableDevice -locationpath $LocationPathOfDismountedDA

We grab the display adapter that’s now back as disabled under device manager of in an “error” status in the display class of the pnpdevices.

#It will now show up in our query for -presentonly NVIDIA GRIDK1 display adapters

#It status will be “Error” (not “Unknown”)

We grab that first entry to enable the display adapter (or do it in device manager)

#Enable the display adapater

Enable-PnpDevice -InstanceId $MyNVidiaGRIDK1[0].InstanceId -Confirm:$false

The GPU is now back and available to the host. When your run you Get-VMHostAssignableDevice it won’t return this display adapter anymore.

We’ve enabled the display adapter and it’s ready for use by the host or RemoteFX again. Finally, we set the memory resources & configuration for the VM back to its defaults before I start it again (PS: these defaults are what the values are on standard VM without ever having any DDA GPU installed. That’s where I got ‘m)

#Let’s set the memory resources on our VM for the GPU to the defaults

Set-VM RFX-WIN10ENT -GuestControlledCacheTypes $False -LowMemoryMappedIoSpace 256MB -HighMemoryMappedIoSpace 512MB

Now tell me all this wasn’t pure fun!

Select Your Language

Single-page

Language and Page Formatting Options

Red hat training.

A Red Hat training course is available for Red Hat Enterprise Linux

Chapter 16. Guest Virtual Machine Device Configuration

Emulated devices are purely virtual devices that mimic real hardware, allowing unmodified guest operating systems to work with them using their standard in-box drivers.
Virtio devices (also known as paravirtualized ) are purely virtual devices designed to work optimally in a virtual machine. Virtio devices are similar to emulated devices, but non-Linux virtual machines do not include the drivers they require by default. Virtualization management software like the Virtual Machine Manager ( virt-manager ) and the Red Hat Virtualization Hypervisor install these drivers automatically for supported non-Linux guest operating systems. Red Hat Enterprise Linux 7 supports up to 216 virtio devices. For more information, see Chapter 5, KVM Paravirtualized (virtio) Drivers .
Assigned devices are physical devices that are exposed to the virtual machine. This method is also known as passthrough . Device assignment allows virtual machines exclusive access to PCI devices for a range of tasks, and allows PCI devices to appear and behave as if they were physically attached to the guest operating system. Red Hat Enterprise Linux 7 supports up to 32 assigned devices per virtual machine. Device assignment is supported on PCIe devices, including select graphics devices . Parallel PCI devices may be supported as assigned devices, but they have severe limitations due to security and system configuration conflicts.

16.1. PCI Devices

Procedure 16.1. Preparing an Intel system for PCI device assignment

Enable the Intel VT-d specifications

Activate Intel VT-d in the kernel

Regenerate config file

Ready to use

Procedure 16.2. Preparing an AMD system for PCI device assignment

Enable the AMD IOMMU specifications

Enable IOMMU kernel support

16.1.1. Assigning a PCI Device with virsh

Procedure 16.3. Assigning a PCI device to a guest virtual machine with virsh

Identify the device

Review device information

Figure 16.1. Dump contents

Determine required configuration details

Add configuration details

Figure 16.2. Add PCI device

On the host, verify that the device to assign has an expansion ROM base address register (BAR). To do so, use the lspci -v command for the device, and check the output for a line that includes the following: Expansion ROM at
Add the <rom bar='off'/> element as a child of the <hostdev> element in the guest's XML configuration: <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0' bus='0' slot='25' function='0'/> </source> <rom bar='off'/> </hostdev>

Start the virtual machine

16.1.2. Assigning a PCI Device with virt-manager

Procedure 16.4. Assigning a PCI device to a guest virtual machine using virt-manager

Open the hardware settings

The virtual machine hardware window with the Information button selected on the top taskbar and Overview selected on the left menu pane.

Figure 16.3. The virtual machine hardware information window

Select a PCI device

The Add new virtual hardware wizard with PCI Host Device selected on the left menu pane, showing a list of host devices for selection in the right menu pane.

Figure 16.4. The Add new virtual hardware wizard

Add the new device

The virtual machine hardware window with the Information button selected on the top taskbar and Overview selected on the left menu pane, displaying the newly added PCI Device in the list of virtual machine devices in the left menu pane.

Figure 16.5. The virtual machine hardware information window

16.1.3. PCI Device Assignment with virt-install

Procedure 16.5. Assigning a PCI device to a virtual machine with virt-install

Figure 16.6. PCI device file contents

Add the device

Complete the installation

16.1.4. Detaching an Assigned PCI Device

Procedure 16.6. Detaching a PCI device from a guest with virsh

Detach the device

Re-attach the device to the host (optional)

Procedure 16.7. Detaching a PCI Device from a guest with virt-manager

Open the virtual hardware details screen

Figure 16.7. The virtual hardware details button

Select and remove the device

The PCI device details and the Remove button.

Figure 16.8. Selecting the PCI device to be detached

16.1.5. PCI Bridges

16.1.6. pci device assignment restrictions, quick links.

Subscriptions
Support Cases
Customer Service
Product Documentation
Contact Customer Portal
Customer Portal FAQ
Log-in Assistance
Trust Red Hat
Browser Support Policy
Accessibility
Awards and Recognition

Related Sites

developers.redhat.com
connect.redhat.com
cloud.redhat.com

Systems Status

Red Hat Subscription Value
About Red Hat
Red Hat Jobs

You are using an outdated browser. Please upgrade your browser to improve your experience.

Device Assignments

You can move devices across organization groups (OG) and user names based on the network Internet protocol (IP) address range or custom attributes using Device Assignments. It is an alternative to organizing content by user groups in Workspace ONE UEM.

Instead of manually moving devices between OGs, you can direct the console to move devices automatically when it connects to Wi-Fi that you define. You can also move devices based on custom attribute rules that you define.

A typical use case for device assignments is a user who regularly changes roles and requires specialized profiles and applications for each role.

You must select between implementing User Groups and Device Assignments to move devices since Workspace ONE UEM does not support both functions on the same device.

NOTE: Windows devices do not support defining IP address ranges. Therefore, Windows devices must use user groups instead of device assignments for moving devices across OGs automatically. You can also move a device based on attributes in Workspace ONE Intelligence or by using a sensor. For details, see Workspace ONE Intelligence and Creating Sensors for Windows Desktop Devices .

Enable Device Assignments

Before you can move devices across organization groups (OG) and user names based on an Internet protocol (IP) or custom attribute, you must enable device assignments in Workspace ONE UEM. Device assignments can only be configured at a child organization group.

Ensure you are in a customer type organization group.
Navigate to Groups & Settings > All Settings > Devices & Users > General > Advanced and select Override or Inherit for the Current Setting according to your needs.
Select Enabled in the Device Assignment Rules setting.

Select the management Type from the following.

Organization Group By IP Range – Moves the device to a specified OG when the device leaves one Wi-Fi network range and enters another. This move triggers the automatic push of profiles, apps, policies, and products.

Organization Group By Custom Attribute – Moves the device to an organization group based on custom attributes.

Custom attributes enable administrators to extract specific values from a managed device and return it to the Workspace ONE UEM console. You can also assign the attribute value to devices for use in product provisioning or device lookup values.

When Organization Group By Custom Attribute is enabled, a link appears entitled Click Here To Create Custom Attribute Based Assignment Rule . When selected, this link opens another tab in your browser. This tab displays the Custom Attribute Assignment Rules page, enabling you to create your own attribute assignment rules.

User name By IP Range – When a device exits one network and enters another, the device changes user names instead of moving to another OG. This user name change triggers the same push of profiles, apps, policies, and products as an OG change does. This option is for customers with a limited ability to create organization groups, providing an alternate way to take advantage of the device assignment feature.

Important: If you want to change the assignment Type on an existing assignment configuration, you must delete all existing defined ranges. Remove IP Range assignments by navigating to Groups & Settings > Groups > Organization Groups > Network Ranges . Remove custom attribute assignments by navigating to Devices > Provisioning > Custom Attributes > Custom Attribute Assignment Rules .

Select the Device Ownership options. Only devices with the selected ownership types are assigned.

Corporate – Dedicated
Corporate – Shared
Employee Owned

You can add a network range by selecting the link, Click here to create a network range .

You can alternatively visit this page by navigating to Groups & Settings > Groups > Organization Groups > Network Ranges . The Network Ranges settings selection is only visible if Device Assignments is enabled for the Organization Group you are in when you visit this location.

When selected, the Network Ranges page is displayed.

Select Save once all the options are set.

Define Device Assignment Rule or Network Range

When your device connects to Wi-Fi while managed by Workspace ONE UEM, the device authenticates and automatically installs profiles, apps, policies, and product provisions specific to the OG that you select.

You can also define rules based on custom attributes. When a device enrolls with an assigned attribute, the rule assigns the device to the configured organization group. The device can also be assigned in the case where the device receives a product provision containing a qualifying custom attribute.

Device assignments can only be configured at a child organization group.

This screenshot shows the Network Ranges screen, which is only visible after you enable device assignments.

Navigate to Groups & Settings > Groups > Organization Groups > Network Ranges .

The Network Ranges option is not visible until you enable device assignments. So if you cannot find ‘Network Ranges’ in the Organization Groups navigation path, see the section above entitled Enable Device Assignments .

To add a single Internet protocol (IP) address range, select Add Network Range . In the Add/Edit Network Range page, complete the following settings and then select Save .

Overlapping network ranges results in the message, “Save Failed, Network Range exists.”

If you have several network ranges to add, you can optionally select Batch Import to save time.

On the Batch Import page, select the Download template for this batch type link to view and download the bulk import template in CSV format.

Open the CSV file. The CSV file features several columns corresponding to the options on the Add Network Range screen. Enter the organization Group ID in the “OrganisationGroup” column instead of organization group name.

Note: You can identify the Group ID of any organization group by 1) moving to the OG you want to identify and 2) hovering your pointer over the OG label which displays a popup that contains the Group ID.

Note: A CSV file (comma-separated values) is simply a text file whose extension is changed from “TXT” to “CSV”. It stores tabular data (text and numbers) in plain text. Each line or row of the file is a data record. Each record consists of one or more fields, separated by commas. It can be opened and edited with any text editor. It can also be opened and edited with Microsoft Excel.

When you open the CSV template, notice that sample data has been added to each column in the template. The sample data is presented to inform you what kind of data is required and what format it must be in. Do not stray from the format presented by the sample data. Complete this template by filling in each of the required columns for each network range you want to add.

Import the completed template using the Batch Import page.

The screenshot shows the Batch Import screen for the Network Range option.

Intune – User vs Device Targeting

Following on from my previous post looking at User vs System deployments in this one I will look at another confusing part, Intune targeting.

An important note – with very few exceptions, there is no right or wrong way to target, this is my opinion and your scenario may differ

Before starting, I would recommend having a look at these posts from Scott Duffey , the expert in everything targeting and filtering:

Microsoft Endpoint Manager: A deep dive on grouping, targeting and filtering
Use Microsoft Endpoint Manager filters to target apps and policies to specific devices
How Application Context, Assignment and Exclusions Work in Intune

The first thing to remember is NEVER mix device and user based targeting due to the way Intune sychronises and queries groups. You could have an application targeting users but with certain devices excluded, but by the time the exclusion has queried, the app could have already installed.

If you have a situation like this where you want users to have an app/policy/script but only on certain devices (laptops for example, or non-BYOD), use a user group with a device based filter on top.

The beauty of filtering is that you can target at users to give a better device-agnostic experience, but still be able to control which devices it targets.

Dynamic and Static Groups

I’m a big fan of dynamic groups, they make on-going estate management easier whether a user or device group. For example, if user A replaces their machine and you have device based targeting on a statically assigned group, you will need to remember to add the new machine and remove the old one from the group. For a small number of users and devices, this is fine, but when you start to look at the multi-thousands, both device replacements and staff churn will be high so it quickly becomes a full time task (plus you’re at the mercy of the HR starters and leavers process).

If you watch the video from Scott above you will see the process for group membership within Intune

Once you add in the time for a dynamic group membership rule to process, you can get a delay when using dynamic groups. I personally think it’s worth the wait, but that depends on your user base.

All Users and All Devices

These are virtual groups available only within Intune.

The All Devices group includes any device enrolled into Intune (including BYOD and all operating systems). It is recommended not to create your own group to simply contain all devices and use this one with filters applied (Corporate owned, Windows OS for example). It’s a quick and easy way of hitting all machines without waiting for processing to complete, but management is entirely within Intune and I prefer to make use of Azure AD so I can use groups for other parts such as Conditional Access and PIM.

It is worth keeping in mind, if you’re using Autopilot, I imagine you’ll already have an Autopilot devices group used during enrollment which is basically all corporate owned Windows devices.

The All Users group is every user in the estate with an Intune license. Again, it works well with filters (to exclude BYOD as an example), but often a dynamic or static group will be easier to manage.

User Targeting

The one situation which ONLY works with user targeting is applications marked as Available to install in the Company Portal. Company Portal runs in the User Context so even applications which run as System need to be targeted to users (when “Available”) to display.

It is also recommended to user User Targeting for any single owner devices with Compliance Policies. Otherwise compliance will run against both the user and SYSTEM account and could cause issues (see here )

Obviously any policies, apps and scripts which run at the user level are best targeted to users, otherwise a user could login to a different machine and have a different experience.

My personal preference is for any non-baseline applications to be user targeted. I would class baseline as the must-have apps on any machine, your security suite, firewalls, VPNs, that type of application. You could include Office in this as well, but that depends on your estate, if you have a mix of F3 and E3 licenses, you may be better off using dynamic user groups to check on the licenses and target appropriately.

It is also worth considering the policies set in your baseline settings. For example, if you have an Android/iOS policy which blocks tethering, but you have a particular subset of users who are going to need it, you are best off removing that setting from your baseline and adding it to a new policy with user-level targeting.

You also need to look at the user personas involved. If you have 1:1 user-device relationship, it doesn’t make a huge difference, but if you have users who roam between devices, especially shared devices, user-based targeting is going to give them the best experience.

So, what happens if you have device-level policies (targeting HKLM for example) with a user group assigned to it and multiple users login to the same device with different policy settings for each user. In this situation, the policy will apply to the logged in user so as each user logs in, the setting assigned to them will apply.

This is worth considering, especially with multi-user shared devices as some HKLM keys may not apply until the next reboot so you could find yourself with the policy technically applying to the subsequent user rather than the current one (and your machines may not appreciate feeling like they are in a kris-kross song).

Device Targeting

Whilst not set in stone, I would include your Pilot/Preview update rings in something that should be Device only targeted. Generally these are aimed at your IT staff initially, who may login to other devices for testing or troubleshooting and the last thing you want is them installing a preview build onto the machine!

Microsoft Defender for Endpoint (MDE) works in the device context so any MDE policies will need to be device targeted.

There are also some security related policies from Config Manager which again won’t work in the user context for those of you working in a co-managed environment.

As mentioned earlier, device targeting works best for your baseline settings which you want to apply to all devices as quickly as possible, so we are looking at the likes of Bitlocker, Windows Defender, anything which you would see as critical and unlikely to ever be drastically changed for different user groups.

When using Autopilot, also consider your PowerShell scripts. When device targeted (and obviously system context), these run early on during the Preparing your Device phase, prior to any user login or any app installations. This is where I would suggest running any bloat removal scripts as you can be sure that you aren’t removing anything you have deployed and also you won’t be competing with any other application installations when running an uninstall.

If you are from a traditional GPO background, think of these as the policies you would set at a high-level within the AD structure and the user targeted as those at lower OU level.

Also worth keeping in mind, device targeting works as long as the machine is switched on, the policy/script/app will apply as soon as the device checks in, even at the login screen. With user targeting, the user needs to be logged on for it to apply.

There is no fixed approach for targeting and often a mixed approach will give the best experience. In modern management, it’s worth remembering that it should be reasonably device agnostic so if you can give the users the same experience across multiple devices and platforms, that will give everyone involved an easier life. With Windows 365 and AVD thrown into the mix, this becomes all the more important.

My preferences tend to lean towards more at the user side with a select few key policies looking at the device, but your requirements may lean more towards device targeting.

As always, comments are most welcome!

28 thoughts on “Intune – User vs Device Targeting”

Hi Andrew, Thanks for the summary and the insights! I have a special use case for Windows Update rings: in my case there are different Insider and Pilot rings which are assigned to dynamic user groups. But in the last Production ring I want to cover all devices essentially, not all users. Because the self-deploying devices or Kiosks may never have a user affinity or assignment. What are your thoughts on that?

Hi Niklas, That’s an interesting one! I would probably use the All Devices group with filtering applied to ignore any devices where the primary user is one of your Insider or Pilot users.

For a managed IT services managing multiple environments that are predominantly azure ad joined, we find targeting user groups with the exception of autopilot profiles (also have as fewer groups as possible) is far easier to manage, train IT staff, troubleshoot and document. The focus is on the user (which makes sense for SaaS solutions) and not the device or both.

Yes, I can fully appreciate that (and have done the same myself). You could of course use your Autopilot devices group for some security policies if you wanted to target devices which cuts out any management tasks on group membership. Policy sets work nicely with user assigned groups, but until they support Win32 apps, I don’t tend to use them much

Not really a thought proving comment here, but I wanted to say that I love this newsletter/website. The information is so well put together and easy to read. I appreciate the logic being used when trying to convey the overall message.

Thank you! I’m so glad you find it useful. If there are any particular subjects you would like covered, I’m always open to suggestions.

Hi Andrew, fantastic article mate! In the comments here, you mention using ‘filtering applied to ignore any devices where the primary user is one of your Insider or Pilot users’. Where/how are you configuring that filter? It’s not one of the currently available selections.

Hi David, glad you’ve found it useful. At the moment, the only way would be to exclude them via Device Name. Ideally your insider and pilot rings are device targeted anyway, but it’s still a manual task to add the device names into the filter (I’d probably do filters for each group) If you have lots of devices, I’m sure it could be automated using Graph to grab members of the AAD group and add them into a filter (happy to help if needed)

Is it possible to target all devices with Attack surface policies, and also exclude a group of dev-users from that ? And create a seocnd dev-users policy that applies different ASR policies?

Not easily, you can’t mix user and device targeting. Your best option would probably be to add a group tag to the dev machines, create a dynamic AAD group on the tag and then exclude that group from the ASR policies.

Unless your devs all use a particular model machine in which case you could use a device filter

Group tag like manually? We don´t use autopilot, that seems to be related to group tag´s?

If you are hybrid, you could use a dynamic AD group based off the machine OU and drop the dev machines into their own one, that might be easier to manage

I have a branding Win32 app (pretty much just a .ps1 file wrapped up as Win32). I’ve applied it to the All Devices and have noticed in Intune that it gets applied to both the actual user who logs in and to the “No User” UPN. What’s the “No User” UPN?

I have this app set as mandatory to install before the user gets to their desktop via the corresponding ESP Profile. Since this is a baseline, I figured All Devices made the most sense, but it seems to be that assigning to All Users would ultimately accomplish the same thing, no? I guess maybe if a new user signed in it would again have to pull down this Win32 app and apply it whereas when using All Devices it only has to run once? Is this the true benefit to the All Devices virtual group in this situation?

Hi, The No User UPN is basically the SYSTEM context on the machine. If you want it as a required app during ESP, targeting the device is absolutely fine and means it runs earlier in the process. Targeting users won’t install every time someone logs in unless it is installing at the user level. If you are installing to the device (Program Files for example), it will detect the app is already there and just ignore it. I hope this helps

Hi Andrew! Thanks for the helpful article.

If I *don’t* want the No User UPN to show up for an app (eg. Microsoft 365 Apps), do I need to target that app to users, rather than to devices? Is that what you’re saying?

Hi, yes, exactly that. If you target devices, it also hits the system account which doesn’t have a UPN

Hello and thank you for such a detailed post.

Regarding the No User, I use the System context to run most of my Win32 apps as System user, as it wouldn’t install if run as user. Is there any way of avoiding this No User installation as it creates a lot of wrong info on the installation statistics of the app?

Best regards

Hi, Is the No User showing as well as the active user, or are you just seeing no user on the app install status? Is the status Failed, or Successful?

Old post but I was interrested in the answer. I do have the problem on some devices where I see duplicate in Intune reports with app install status showing “no user” failed but current user of the device is marked as installed.

Are they device targeted apps/policies?

Excellent advice Andrew. Thank you for posting. Just adding what I do with our estate (to make administration a little easier) I base group membership on device naming where possible, because we have 4 type of devices and 2 organisations. Therefore, I use smart naming for the devices. Example: Laptop for company 1 that is deployed through Autopilot might be named: LT-C1-AP-003 This means I can dynamically assign group membership based on name ‘contains’.

That sounds like a good option, thank you!

If you are targeting a user group with a configuration profile, which applies device level settings and the user logs out of the device, will those settings be removed in subsequent syncs? For example, user logs out of device, device sits idle and powered on over a weekend, intune’s scheduled sync tasks run, what would be the expected result?

The setting will remain until someone else logs in with a different setting. Whilst you are targeting a user group, the profile is still applying to the HKLM hive so remains on the machine until it receives a different setting

really excellent post and series of posts. We are new to intune/autopilot and have a couple of scripts wrapped in win32 which should only run in OOBE/ESP system context. the apps are assigned to devices only, no users, however when we look at the app overview it seems to be installed in both the system context and the logged on user.

the script has a requirement that it should only run in OOBE/ESP via HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\defaultuser=defaultuser0

any ideas why both device and user are getting the app/script?

many thanks

Hi, Do you have a requirements rule to make sure it doesn’t run outside OOBE? Something like this: https://oofhours.com/2023/09/15/detecting-when-you-are-in-oobe/

Is there content in the script which would be visible at the user-level, it could just be Intune reporting showing it as installed for the user

Hi Andrew, What do you recommend when deploying a Wi-Fi policy to user or device groups?

Hi, How is your Wi-Fi configured? Normally I would suggest user groups, but something like pki may work better at the device level

User Guide for Cisco Device Assignment Tool

Bias-free language.

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Overview of the Cisco Device Assignment Tool

System Preparation for the Cisco Device Assignment Tool
Using the Cisco Device Assignment Tool
Troubleshooting the Cisco Device Assignment Tool

Chapter: Overview of the Cisco Device Assignment Tool

Cisco device assignment tool overview, system requirements for cisco device assignment tool.

Use the Cisco Device Assignment Tool ( Device Assignment Tool ) to assign users to devices in Cisco Unified Communications Manager Releases 6.x and later. This tool helps simplify your licensing when you upgrade your system and your existing users do not have assigned devices. In user-based licensing, devices are assigned to users to simplify self care and device management for you. From a licensing standpoint, devices that users own share a license, instead of requiring a separate license for both a device and a user.

The tool connects to your system and reads the configured devices that are not assigned to users. Using rules that you select, the tool matches users to unassigned devices. You can review the user-to-device matches, make manual changes if needed, and then apply the results in the Cisco Unified Communications Manager database.

For more information about licensing for Cisco Unified Communications Manager , Releases 10.x and earlier, see the the "Licensing" chapter in the Cisco Unified Communications Manager Features and Services Guide here .

For Releases 11.x and later, see the System Configuration Guide for Cisco Unified Communications Manager here .

This tool is a standalone desktop application that can run on a Windows PC or an Apple Mac computer. System requirements are as follows:

A Unified Communications Manager node, Release 6.x or later, that is running AXL web services (see "Enable the AXL Web Service" in the Related Topics section)

A PC that is running Windows 7 or later, or an Apple Mac computer that runs OS X 10.8 (Mountain Lion) or later.

A minimum of 1 GB memory

A minimum of 100 MB free hard drive space

Java 1.8 or later

A program that lets you view and edit spreadsheet files in .xls format

Was this Document Helpful?

Contact Cisco

(Requires a Cisco Service Contract )

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Monitor device configuration policies in Microsoft Intune

8 contributors

Intune includes some features to help monitor and manage your device configuration policies. For example, you can check the status of a policy, go to the devices are assigned to the policy, and update the properties of an existing policy.

This article shows you how to view existing device configuration policies for assignment status, making changes, and how to troubleshoot any conflicts.

View existing policies

Sign in to the Microsoft Intune admin center .
Select Devices > Configuration > Policies tab.

All of your policies are shown. You also see the platform, the type of policy, and if the policy is assigned.

For more in-depth reporting information about device configuration policies, go to Intune reports .

View details on a policy

After you create your device configuration policy, Intune provides reporting data. These reports show the status of a policy, such as it being successfully assigned to devices, or if the policy shows a conflict.

In Devices > Configuration > Policies tab, select an existing policy.

The Device and user check-in status shows the number of all users or devices that checked-in with the policy. If one device has multiple users, this report shows the status for each user. When the user or device checks in with Intune, they receive the settings in your policy.

The following statuses are shown:

Succeeded : The policy is applied successfully.
Error : The policy failed to apply. The message typically displays with an error code that links to an explanation.
Conflict : Two settings are applied to the same device, and Intune can't sort out the conflict. An administrator should review.
Pending : The device hasn't checked in with Intune to receive the policy yet.
Not applicable : The device can't receive the policy. For example, the policy updates a setting specific to iOS 11.1, but the device is using iOS 10.

Device assignment status shows information for the user that last checked-in. Select Generate report to see the latest policy assignment states for the devices that received the policy. You can also filter the assignment status to see only errors, conflicts, and more.

It's normal for the numbers in the Device and user check-in status and Device assignment status reports to be different.

Per setting status shows the individual settings in the policy, and their status.

Back in Device and user check-in status , select View report :

View report shows more information on the devices assigned to that specific device configuration policy, including:

The devices that received the policy
The user names with devices that received the policy
The check-in status and the last time the user/device checked in with the policy

You can also select a specific device to get more details and use the filter column to see the assignment filter options.

Back in Device and user check-in status , the following property information for the specific policy is available for you to view and edit:

Basics : See the policy name and description.
Assignments : See the users and groups that receive policy, and see any existing filters in the policy.
Scope tags : See any existing scope tags used in the policy.
Configuration settings : See the settings you configured in the policy.
Applicability Rules : On your Windows devices, go to the applicability rules used in the policy.

View details on all device configuration policies

Go to Devices > Configuration > Monitor tab:

In this area, you have access to the Configuration policy assignment failures report. This report helps troubleshoot errors and conflicts for configuration policies that are assigned.

This area also provides quick access to the following reports:

Devices with restricted apps
Device encryption status
Certificates

In Devices , select Monitor . This area lists all reports you can use, including reports for device configuration, compliance, enrollment, and software updates. For more information on all the Intune reports, go to Intune reports .

View conflicts

In Devices > All devices , you can see any settings that are causing a conflict. When there's a conflict, you also see all the configuration policies that contain this setting.

Administrators can use this feature to help troubleshoot, and fix any discrepancies with the policies.

In Intune, select Devices > All Devices > select an existing device in the list. An end user can get the device name from their Company Portal app.
Select Device configuration . All configuration policies that apply to the device are listed.
Select the policy. It shows you all the settings in that policy that apply to the device. If a device has a Conflict state, select that row. In the new window, you see all the policies, and the profile names that have the setting causing the conflict.

Now that you know the conflicting setting, and the policies that include that setting, it should be easier to resolve the conflict.

Device Firmware Configuration Interface (DFCI) profile reporting

DFCI policies are reported on a per-setting basis, just like other device configuration policies. Depending on the manufacturer's support of DFCI, some settings might not apply.

With your DFCI profile settings, you might see the following states:

Compliant : This state shows when a setting value in the profile matches the setting on the device. This state can happen in the following scenarios:

The DFCI profile successful configured the setting in the profile.
The device doesn't have the hardware feature controlled by the setting, and the profile setting is Disabled .
UEFI doesn't allow DFCI to disable the feature, and the profile setting is Enabled .
The device lacks the hardware to disable the feature, and the profile setting is Enabled .

Not Applicable : This state shows when a setting value in the profile is Enabled or Allowed , and the matching setting on the device isn't found. This state can happen if the device hardware doesn't have the feature.

Noncompliant : This state shows when a setting value in the profile doesn't match the setting on the device. This state can happen in the following scenarios:

UEFI doesn't allow DFCI to disable a setting, and the profile setting is Disabled .
The device lacks the hardware to disable the feature, and the profile setting is Disabled .
The device doesn't have the latest DFCI firmware version.
DFCI was disabled before being enrolled in Intune using a local "opt-out" control in the UEFI menu.
The device was enrolled to Intune outside of Autopilot enrollment.
The device isn't registered to Windows Autopilot by a Microsoft CSP, or registered directly by the OEM.

Additional resources

Success! Subscription added.

Success! Subscription removed.

Sorry, you must verify to complete this action. Please click the verification link in your email. You may re-send via your profile .

Intel Community
Product Support Forums
Programmable Devices

Error(18210): LogicLock region assignments cannot be used in Quartus Prime Pro Edition. Remove these

Subscribe to RSS Feed
Mark Topic as New
Mark Topic as Read
Float this Topic for Current User
Printer Friendly Page

Mark as New
Report Inappropriate Content

Configuration (FPGA)

All forum topics
Previous topic

Link Copied

Community support is provided during standard business hours (Monday to Friday 7AM - 5PM PST). Other contact methods are available here .

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

For more complete information about compiler optimizations, see our Optimization Notice .

Terms of Use
*Trademarks
Supply Chain Transparency

Discrete Device Assignment — Machines and devices

Firmware, including bios and uefi, must cooperate, beyond the bios, individual devices may or may not be candidates for passing through to a vm, survey the machine.

First published on TECHNET on Nov 20, 2015

In my last post , I talked about a new feature of Windows Server 2016 , Discrete Device Assignment. This post will discuss the machines and devices necessary for making this feature work.

First, we're not supporting Discrete Device Assignment in Hyper-V in Windows 10. Only Server versions of Windows support this. This isn't some wanton play for more of your hard-earned cash but rather just a side effect of being comfortable supporting server-class machines. They tend to work and be quite stable.

Second, in order to pass a device through to a guest VM , we have to change the way parts of the PCI Express fabric in the machine are configured. To do this, we need the firmware (BIOS, UEFI, whatever) in the machine to agree that it won't change the very same parts of PCI Express that Windows is changing while the machine is running. (Yes, the BIOS does actually do things while the machine is running.) So, in accordance with the PCI firmware specification, Windows asks the firmware for control of several different parts of PCIe.

This protocol was created when PCIe was new, largely because Windows XP, Windows Server 2003 and many other operating systems were published before the PCI Express specification was done. BIOSes in these machines needed to manage PCIe. Windows, or any other operating system, essentially asks the BIOS whether it is prepared to give up this control. The BIOS responds with a yes or a no. If you BIOS responds with a no, then we don't support Discrete Device Assignment because we may destabilize the machine when we enable it.

Another requirement of the underlying machine is that it exposes “Access Control Services” in the PCI Express Root Complex. Pretty much every machine sold today has this hardware built into it. It allows a hypervisor (or other security-conscious software) to force traffic from a PCI Express device up through the PCIe links (slots, motherboard wires, etc.) all the way to the I/O MMU in the system. This shuts down the attacks on the system that a VM might make by attempting, for instance, to read from the VRAM by using a device to do the reading on its behalf. And while nearly all the silicon in use by machine makers supports this, not all the BIOSes expose this to the running OS/hypervisor.

Lastly, when major computer server vendors build machines, sometimes the PCI Express devices in those machines are tightly integrated with the firmware. This might be, for instance, because the device is a RAID controller, and it needs some RAM for caching. The firmware will, in this case, take some of the installed RAM in the machine and sequester it during the boot process, so that it's only available to the RAID controller. In another example, the device, perhaps a NIC , might update the firmware with a health report periodically while the machine runs, by writing to memory similarly sequestered by the BIOS. When this happens, the device cannot be used for Discrete Device Assignment, as exposing it to a guest VM would both present a considerable security risk and because the view of memory from within the guest VM is entirely different than the view of the actual system hardware, and thus the attempts by the devices to read and write this private memory would fail or corrupt other memory.

There are a lot of other low level requirements, many of them documented by John Howard in his SR-IOV series, but most of the machines in the world will conform with them, so I won't go into more detail now.

Some devices in your computer don't mark, or tag, their traffic in way that individually identifies the device, making it impossible for the I/O MMU to redirect this traffic to the memory owned by a specific VM. These devices, mostly older PCI-style logic, can't be assigned to a guest VM.

All of the devices inside your computer have some means to control them. These controls are built out of “registers” which are like locations in computer memory, but where each location has a special purpose, and some sort of action that happens when the software reads or writes that location. For instance, any devices have “doorbell” registers which tell them that they should check work lists in memory and do the work described by what is queued up on the work lists. Registers can be in locations in the computer's memory space, in which case they're commonly called “memory-mapped I/O” and the processor's page tables allow the hypervisor to map the device's register into any VM . But registers can also be in a special memory-like space called “I/O space.” When registers are in I/O space, they can't be redirected by the hypervisor, at least not in a friction-free way that allows the device and the VM to run at full speed. As an example, USB 1 controllers use I/O ports. USB 3 controllers use memory-mapped I/O space. So USB 3 controllers might meet the criteria for passing through to a guest VM in Hyper-V .

PCI-style devices have two possible ways to deliver interrupts to the CPUs in a computer. They can connect a pin to a ground signal, somewhat like unplugging a light bulb, or they can write to a special location in the processor directly. The first mechanism was invented many years ago, and works well for sharing scarce “IRQs” in old PCs. Many devices can be connected to the same metaphorical light bulb, each with its own stretch of extension cord. If any device in the chain wants the attention of the software running on the CPU, it unplugs its extension cord. The CPU immediately starts to run software from each device driver asking “was it you who unplugged the cord?” The problem comes in that, when many devices share the same signal, it's difficult to let one VM manage one of the devices in that chain. And since this mechanism of delivering interrupts is both deprecated and not particularly common for the devices people use in servers, we decided to only support the second method of delivering interrupts, which can be called Message-Signaled Interrupts, MSI or MSI-X, all of which are equivalent for this discussion.

Some of the properties discussed are easily seen in the Device Manager. Here's the keyboard controller in the machine that I'm typing this with. It fails all the tests described above.

And here's a USB 3 controller. The Message-Signaled Interrupts show up as IRQs with negative numbers. This device happens to pass all the tests.

To help you all sort this out, I've written a script which surveys the machine and the devices within it, reporting on which of them meet the criteria for passing them through to a VM.

https://github.com/Microsoft/Virtualization-Documentation/tree/master/hyperv-samples/benarm-powershell/DDA

You can download it by running the following command in PowerShell:

wget https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/master/hyperv-samples/benarm-powershell/DDA/survey-dda.ps1

In my HP server machine, this returns a long list, including entries like:

Smart Array P420i Controller BIOS requires that this device remain attached to BIOS-owned memory. Not assignable.

Intel(R) C600/X79 series chipset USB2 Enhanced Host Controller #2 – 1D2D Old-style PCI device, switch port, etc. Not assignable.

NVIDIA GRID K520 Express Endpoint — more secure. And its interrupts are message-based, assignment can work. PCIROOT(0)#PCI(0300)#PCI(0000)#PCI(0800)#PCI(0000)

The first two entries are for devices which can't be passed through to a VM. The first is in side-band communication with the HP management firmware, and the HP BIOS stipulates that communication channel must not be broken, which would happen if you passed the device through to a VM . The second is for a USB 2 controller that's embedded in the Intel chipset. It's actually old-style PCI logic, and thus the I/O MMU can't tell its traffic from any other device's so it can't handle being giving addresses relative to a guest VM.

The last entry, for the NVIDIA GRID K520, is one where the device and the machine meet the criteria for passing it through to a guest VM. The last line shows the “location path” for this GPU, which is in terms of “first root PCI bus; bridge at device 3, function 0; bridge at device 0, function 0; bridge at device 8, function 0; device 0 function 0.” This string isn't going to change, even if you plug in another device somewhere else in the machine. The classic way of describing a PCI device, by bus number, device number and function number can change when you add or remove devices. Similarly, there are things that can affect the PnP instance path to the device that Windows stores in the registry. So I prefer using this location path, since it's durable in the face of changes.

There's another sort of entry that might come up, one where the report says that the device's traffic may be redirected to another device. Here's an example:

Intel(R) Gigabit ET Dual Port Server Adapter Traffic from this device may be redirected to other devices in the system. Not assignable.

Intel(R) Gigabit ET Dual Port Server Adapter #2 Traffic from this device may be redirected to other devices in the system. Not assignable.

What this is saying is that memory reads or writes from the device targeted at the VM 's memory (DMA) might end up being routed to other devices within the computer. This might be because there's a PCI Express switch in the system, and there are multiple devices connected to the switch, and the switch doesn't have the necessary mechanism to prevent DMA from one device from being targeted at the other devices. The PCI Express specifications optionally allow all of a device's traffic to be forced all the way up to the I/O MMU in the system. This is called “Access Control Services” and Hyper-V looks for that and enables it to be sure that your VM can't affect others within the same machine.

These messages also might show up because the device is “multi-function” where that means that a single chip has more than one thing within it that looks like a PCI device. In the example above, I have an Intel two-port gigabit Ethernet adapter. You could theoretically assign one of the Ethernet ports to a VM, and then that VM could take control of the other port by writing commands to it. Again, the PCI Express specifications allow a device designer to put in controls to stop this, via Access Control Services (ACS).

The funny thing is that the NIC above has neither the ACS control structure in it nor the ability to target one port from the other port. Unfortunately, the only way that I know this is that I happened to have discussed it with the man at Intel who led the team that designed that NIC . There's no way to tell in software that one NIC port can't target the other NIC port. The official way to make that distinction is to look for ACS in the device. To deal with this, we allow you to override the ACS check when dismounting a PCI Express device. (Dismount-VMHostAssignableDevice -force)

Forcing a dismount will also be necessary for any device that is not supported. Below is the output of an attempt to dismount a USB 3 controller without forcing it. The text is telling you that we have no way of knowing whether the operation is secure. And without knowing all the various vendor-specific extensions in each USB 3 controller, we can't know that.

PS C:> Dismount-VMHostAssignableDevice -LocationPath “PCIROOT(40)#PCI(0100)#PCI(0000)”

Dismount-VMHostAssignableDevice : The operation failed. The manufacturer of this device has not supplied any directives for securing this device while exposing it to a virtual machine . The device should only be exposed to trusted virtual machines. This device is not supported when passed through to a virtual machine. The operation failed. The manufacturer of this device has not supplied any directives for securing this device while exposing it to a virtual machine.

Use the “-force” options only with extreme caution, and only when you have some deep knowledge of the device involved. You have been warned.

Read the next post in this series: Discrete Device Assignment — GPUs

— Jake Oshins

This article was originally published by Microsoft's Data Center Security Blog . You can find the original article here .

Windows Subsystem for Linux for testing Windows 10 PTP Client
Windows Server 2025 vs 2022: Detailed Overview
Windows Server 2016/2019 Cluster Resource / Resource Types
Windows Server 2016 Software Defined Networking: Updating the Network Controller Server certificate
Windows Server 2012 Storage Migration for Cluster Managed Virtual Machines

20 Security Issues Found in Xiaomi Devices

Oversecured found and resolved significant mobile security vulnerabilities in Xiaomi devices. Our team discovered 20 dangerous vulnerabilities across various applications and system components that pose a threat to all Xiaomi users. The vulnerabilities in Xiaomi led to access to arbitrary activities, receivers and services with system privileges, theft of arbitrary files with system privileges, disclosure of phone, settings and Xiaomi account data, and other vulnerabilities.

We reported these vulnerabilities within 5 days from April 25 to April 30, 2023, to Xiaomi for swift remediation. This article provides a detailed walkthrough of each vulnerability, emphasizing the importance of proactive security practices in mobile technology.

Security - intent redirection with system privileges, system tracing - shell command injection, settings - binding arbitrary services with system privileges, settings - theft of arbitrary files with system privileges, settings - implicit broadcasts expose bluetooth and wi-fi data, settings - implicit activity intents expose xiaomi account, wi-fi, bluetooth data, and phone numbers, getapps - memory corruption, getapps - intent redirection (1), getapps - intent redirection (2), getapps - implicit activity intents expose the session token, security core component - automatically removing the current user, security core component - starting arbitrary broadcast receivers with system privileges, miui bluetooth - theft of arbitrary files with android.uid.bluetooth privileges, miui bluetooth - implicit broadcast intents expose bluetooth data, phone services - implicit activity intents expose telephony data, shareme - hardcoded des key is used to handle private files, gallery - gaining access to arbitrary* content providers, xiaomi cloud - xss in the built-in webview, print spooler - (over-) writing arbitrary files, mi video - implicit broadcasts expose xiaomi account info, conclusions.

Oversecured scan report for the Security app ( com.miui.securitycenter ) contained the following vulnerability:

The exported activity com.miui.wakepath.ui.ConfirmStartActivity is designed to ask the user for permission to start an activity. However, it does not provide any explanation about the dangers of doing so. In addition, an attacker can control the caller and callee names.

Furthermore, this application is declared with the android:sharedUserId="android.uid.system" flag, which makes it a system application. Such applications have many more privileges than any other application. For example, in the context of this vulnerability, an attacker would be able to access arbitrary activities of all applications installed on the user’s device. This includes activities that have the android:exported="false" flag or have the permissions set for access.

Proof of Concept

To test this, we used our own NotExportedActivity activity, which has the android:exported="false" flag:

And launch it through that vulnerability:

Oversecured scan report for the System Tracing app ( com.android.traceur ) contained the following vulnerability:

This app also comes from AOSP, but has been modified by Xiaomi. They added custom code to extend the dump functionality to the exported com.android.traceur.AppReceiver receiver, which does not check the received values and passes them directly to sh .

This app also comes from AOSP, but has been patched by Xiaomi. They changed the code in com.android.settings.wifi.dpp.WifiDppEnrolleeActivity , replacing the original initial inheritor of androidx.appcompat.app.AppCompatActivity with miuix.appcompat.app.AppCompatActivity . It has the miuix.appcompat.app.AppDelegate delegate which calls miuix.appcompat.app.floatingactivity.multiapp.MultiAppFloatingActivitySwitcher.install() where it accepts the attacker controlled values floating_service_pkg and floating_service_path . These values are treated as the component name used to bind the service. We believe this is an SDK issue as it is present in many Xiaomi apps, making them vulnerable. This is dangerous because an attacker can launch any potentially sensitive functionality in all apps installed on the user’s device.

Moreover, as in the previous vulnerability, Settings is a system app, so this functionality allows the attacker to bind absolutely any service declared on the user’s device in any of the installed apps.

As previously, we used our own MyNotExportedService to test the vulnerability:

This code triggers the service:

Similar to the previous vulnerability, Xiaomi added the exported com.android.settings.bluetooth.MiuiFastConnectResourceProvider provider to the app. This provider requests a system permission to read files, but does not internally check if the file access flag is set to read files. In addition, the provider code contains attempts to protect against bad URIs, but they are insufficient. For example, the two validations uri.toString().endsWith(".zip") && !uri.toString().contains("../") can be bypassed using URI tricks such as encoding and URI hash part.

Xiaomi added its own functionality for additional settings that were not present in AOSP. As a result, these intents began to leak information about Bluetooth devices, connected Wi-Fi networks, and emergency contacts.

File AndroidManifest.xml :

File MyReceiver.java :

File DumpUtils.java :

This vulnerability is similar to the previous one, but the only difference is the way to intercept the implicit intents, it’s using activity instead of receiver , and also in the leaked data: it additionally includes Xiaomi account details and filtered phone numbers.

File InterceptActivity.java :

This vulnerability comes from the LiveEventBus library. We informed the developer more than a year ago, but apparently they still haven’t read our message and have not released any updates to the library.

The problem is an insecure broadcast receiver registered in the com/jeremyliao/liveeventbus/core/LiveEventBusCore.java file. A third-party application installed on the same device can send a broadcast with the intent.action.ACTION_LEB_IPC action and specify arbitrary JSON data. The attacker could then use the Gson library to create arbitrary Java objects, including those containing native pointers. This will result in memory corruption if these objects are destroyed. We described this attack vector in more detail in the article Exploiting Memory Corruption Vulnerabilities in Android when we found a similar bug in PayPal applications.

The com.xiaomi.market.ui.MainUserAgreementActivity activity is exported and its base BaseUserAgreementActivity activity takes the targetIntent parameter, validates that it’s launching an activity from GetApps, and passes this intent to startActivity() . This allows an attacker to access any activities of this application that aren’t exported. Additionally, an attacker can access, e.g., com.xiaomi.market.ui.UnlockActivity as a proxy to redirect the intent to other apps due to missed validation in it.

The app contains an exported com.xiaomi.market.appchooser.AppChooserActivity activity that passes an attacker-controlled targetIntent to startActivity() , allowing an attacker to access any not exported activities declared in the app.

This time we launched DebugPreferenceFragmentActivity :

In the com/xiaomi/market/h52native/utils/ClickTriggerUtil.java file, the app uses implicit intents that expose sensitive data such as Xiaomi session tokens to all third-party apps installed on the same device.

Next, the proof of concept dumps the received data in InterceptActivity .

The application contains an exposed dynamically registered broadcast receiver in the com/miui/securityspace/service/SecondSpaceService.java file. When it receives a broadcast with the com.miui.securitycore.ACTION_TO_REMOVE_USER action, it stops the current user, deletes it, and then locks the screen.

As you can see in the screenshot, the problem is that the app resets the component value but keeps the selector. When an attacker sends a broadcast to this receiver, they can provide both values and the intent will be delivered to the Xiaomi receiver first, but after that, it will be redirected to a receiver provided by the attacker. However, the action can only be android.intent.action.MEDIA_SCANNER_SCAN_FILE or miui.intent.action.MEDIA_SCANNER_SCAN_FOLDER , that’s the only restriction here. This vulnerability allows an attacker to access arbitrary receivers of arbitrary applications installed on the same device. This happens because this is a system application and has access to absolutely all broadcast receivers registered in any of the applications installed on the user’s device.

As with previous Intent redirection vulnerabilities, we used our own MyNotExportedReceiver to test the vulnerability:

This code triggers the receiver:

The application includes the exported com.android.bluetooth.ble.app.headset.HeadsetProvider provider. It doesn’t somehow validate the resulting File object, allowing an attacker to perform a path traversal attack. It is also declared with the android:sharedUserId="android.uid.bluetooth" flag, allowing it to access other applications with the same flag and some other privileges.

For testing, we used a file on the SD card:

As you can see in the screenshots, the app does not request permissions from the receivers of these broadcasts, but it does disclose information about the connected Bluetooth devices. However, it is typical in Android to request at least the android.permission.BLUETOOTH permission to access any Bluetooth data.

Next, the proof of concept dumps the received data in MyReceiver .

This app also comes from AOSP, but has been patched by Xiaomi. They added custom functionality, but it was vulnerable to implicit intent hijacking that exposed system values such as ICCID or IMSI of virtual SIMs.

This key is used to encrypt information about private files, which are then stored on the SD card in the /sdcard/ShareMe/safebox/ directory.

The following code should be used to decrypt the data:

The application launches an implicit intent to select a URI for the user’s avatar. This intent can be intercepted by any third-party application installed on the same device. Then the app contains 2 bugs at once: automatically granting read permissions to all applications that can handle the com.android.camera.action.CROP action (for this purpose it is enough to create any exported activity that has a corresponding intent-filter ) and then launching this intent with flag 1 ( Intent.FLAG_GRANT_READ_URI_PERMISSION ) and the attacker’s URI in the data field, which allows to intercept this intent and also read data from this URI. This vulnerable code is present in several Xiaomi apps.

The com/miui/cloudservice/hybrid/ShareLocationHybridActivity.java file contains an unprotected dynamically registered broadcast receiver that takes the push_data value, concatenates it to JS code, and then executes it.

Before testing, the Xiaomi Cloud app needs to be launched, so it registers the dynamic broadcast receiver:

This app also comes from AOSP, but has been patched by Xiaomi. The app processes third-party URIs in the exported com.android.printspooler.convertpdf.ConvertPdfAlertActivity activity. It automatically caches the content from it and uses the attacker-controlled _display_name value to form the output file path. The application uses the androidx.documentfile AndroidX library. However, both it and Android Framework classes such as android.provider.DocumentsProvider do not validate values in any way. This allows the attacker to inject special characters like / and extend the attack.

File MainActivity.java :

File MyContentProvider.java :

The application uses implicit intents to send information (such as the user’s name and email) via broadcasts. Any third-party application can intercept these broadcasts using its own broadcast receivers.

By incorporating mobile vulnerability scanners into the development process, development teams can identify and remediate security vulnerabilities before release, reducing the likelihood of exploitation and data breaches. This proactive approach significantly enhances product security and ensures the safety of end-users.

If you want to enhance your mobile app’s security, explore Oversecured for comprehensive vulnerability scanning. Contact us to learn more or arrange a demo.

Thank you for reaching out

An email with the requested files will be sent to the email address you provided shortly.

Your message was sent. Thank you!

Our specialists will contact you soon.

Protect your apps today!

It can be challenging to keep track of security issues that appear daily during the app development process. Drop us a line and we'll help you automate this process internally, saving tons of resources with Oversecured.

This website uses cookies to improve your experience. See our Privacy Policy to learn more.

IMAGES

Device Assignment with Nested Guests and DPDK
Intune Policy Device Assignment Status Report HTMD Blog
Enrolling Apple devices using Automated Device Enrollment (ADE)
Device Assignment with Nested Guests and DPDK
Intune Policy Device Assignment Status Report HTMD Blog
Device assignment examples: applying for 6 devices using three

VIDEO

Week 05
Device Assignment for VMs in Kubernetes
Hospital Uses Tubes and Catheters Part 2// Tubes and Catheters Used in Hospital #hospitalequipments
Subscribe For Daily Medical Related Shorts #medical #nursing#nursingnotesanddiagramhelp
National AIDS Control Program //NACP #msn #aids
Procedure File On Oral Care // Oral Care Procedure #nursingprocedure #nursingschool

COMMENTS

Device Assignment
Device Management. Enable activation lock on a remote device. Get the details on a set of devices. Get a list of devices that are managed by the server. Get updates about the list of devices the server manages. Notify Apple's servers that your organization no longer owns the specified devices. Retrieves the beta enrollment tokens available for ...
Deploy graphics devices by using Discrete Device Assignment
Starting with Windows Server 2016, you can use Discrete Device Assignment (DDA) to pass an entire PCIe device into a virtual machine (VM). Doing so allows high performance access to devices like NVMe storage or graphics cards from within a VM while being able to apply the device's native drivers. For more information on devices that work and ...
Plan for deploying devices by using Discrete Device Assignment
Get the location path by using Device Manager. Open Device Manager and locate the device. Right-click the device and select Properties. On the Details tab, expand the Property drop-down menu and select Location Paths. Right-click the entry that begins with PCIROOT and select Copy to get the location path for the device.
Passing through devices to Hyper-V VMs by using discrete device assignment
Summary: Learn how to attach a device from your Hyper-V host to your VM by using a new feature of Windows Server 2016. Today we have a guest blogger, Rudolf Vesely, who has blogged here on previous occasions. ... One feature that drew my attention is a new feature in Hyper-V called discrete device assignment. It can be very simply described as ...
Discrete Device Assignment -- Description and background
Discrete Device Assignment -- Description and background. With Windows Server 2016, we're introducing a new feature, called Discrete Device Assignment, in Hyper-V. Users can now take some of the PCI Express devices in their systems and pass them through directly to a guest VM. This is actually much of the same technology that we've used for SR ...
How to deploy graphics devices using Hyper-V DDA
There are three main steps in performing a Discrete Device Assignment of a GPU: Preparing the VM, dismounting the Peripheral Component Interconnect Express, or PCIe, device from the host partition and making the device assignment within the VM. Admins must perform all three of these steps within PowerShell.
Discrete Device Assignment -- Machines and devices
First, we're not supporting Discrete Device Assignment in Hyper-V in Windows 10. Only Server versions of Windows support this. This isn't some wanton play for more of your hard-earned cash but rather just a side effect of being comfortable supporting server-class machines. They tend to work and be quite stable.
Device Management
Overview. Deploying a mobile device management (MDM) solution allows administrators to securely and remotely configure enrolled devices. Administrators use Apple School Manager or Apple Business Manager to enroll organization-owned devices, and users can enroll their own devices. Once a device is enrolled, administrators can update software and ...
PDF Introduction to Windows Server 2016 Hyper-V Discrete Device Assignment
Introduction. Discrete Device Assignment (DDA, also known as PCI Passthrough) is a performance enhancement in Microsoft Windows Server 2016 and Hyper-V. It allows a specific physical PCIe device installed on the host system to be directly and exclusively controlled by a guest virtual machine (VM). In this paper we describe the steps of how to ...
Setting up Discrete Device Assignment with a GPU
As we directly assign the hardware to VM we need to install the drivers for that hardware inside of that VM just like you need to do with real hardware. I refer you to the starting blog of a series on DDA in Windows 2016: Discrete Device Assignment — Description and background; Discrete Device Assignment — Machines and devices
Discrete Device Assignment -- GPUs
Discrete Device Assignment -- GPUs ‎Mar 21 2019 04:55 PM. First published on TECHNET on Nov 23, 2015 This is the third post in a four part series. My previous two blog posts talked about Discrete Device Assignment ( link ) and the machines and devices necessary ( link ) to make it work in Windows Server 2016 TP4. This post goes into more ...
Chapter 12. PCI Device Assignment
Device assignment allows virtual machines exclusive access to PCI devices for a range of tasks, and allows PCI devices to appear and behave as if they were physically attached to the guest operating system. Device assignment is supported on PCI Express devices, except graphics cards. Parallel PCI devices may be supported as assigned devices ...
Chapter 16. Guest Virtual Machine Device Configuration
Procedure 16.1. Preparing an Intel system for PCI device assignment. Enable the Intel VT-d specifications. The Intel VT-d specifications provide hardware support for directly assigning a physical device to a virtual machine. These specifications are required to use PCI device assignment with Red Hat Enterprise Linux.
Discrete Device Assignment -- Description and background
First published on TECHNET on Nov 19, 2015. With Windows Server 2016, we're introducing a new feature, called Discrete Device Assignment, in Hyper-V. Users can now take some of the PCI Express devices in their systems and pass them through directly to a guest VM. This is actually much of the same technology that we've used for SR-IOV networking ...
Assign device profiles in Microsoft Intune
For example, to assign a device configuration profile: Go to Devices > Configuration. All the profiles are listed. Select the policy you want to assign > Properties > Assignments > Edit: Under Included groups or Excluded groups, choose Add groups to select one or more Microsoft Entra groups.
Device Assignments
Device Assignments. You can move devices across organization groups (OG) and user names based on the network Internet protocol (IP) address range or custom attributes using Device Assignments. It is an alternative to organizing content by user groups in Workspace ONE UEM. Instead of manually moving devices between OGs, you can direct the ...
Discrete Device Assignment
First published on TECHNET on Nov 19, 2015 With Windows Server 2016, we're introducing a new feature, called Discrete Device Assignment, in Hyper-V. Users can now take some of the PCI Express devices in their systems and pass them through directly to a guest VM.This is actually much of the same technology that we've used for SR-IOV networking in the past.
Intune
Also worth keeping in mind, device targeting works as long as the machine is switched on, the policy/script/app will apply as soon as the device checks in, even at the login screen. With user targeting, the user needs to be logged on for it to apply. There is no fixed approach for targeting and often a mixed approach will give the best experience.
User Guide for Cisco Device Assignment Tool
Use the Cisco Device Assignment Tool (Device Assignment Tool) to assign users to devices in Cisco Unified Communications Manager Releases 6.x and later. This tool helps simplify your licensing when you upgrade your system and your existing users do not have assigned devices. In user-based licensing, devices are assigned to users to simplify ...
How to set up Device Memory Mode Lighting and Key Assignments ...
Click on "Key Assignments" to show the different remapping and macro options for your device. Again, this will be more limited than using software profiles and will also vary greatly depending on the device you are using. After selecting your key assignment select a key to bind it to and configure the action.
Google Classroom
Google Classroom is a great app for assignments and the classroom in general, but there's some problems on the go for mobile users. I have a Google Pixel 8 (amazing phone), and when I'm on the go, no matter the network, albeit 5G, 5G UC (T-Mobile), or my Gigabit wifi at home, the app still opens really slowly and takes around 15-30 seconds to load a class page.
How to: Set up Corsair gaming keyboards in iCUE 4 and newer
Open iCUE. On the home screen, hover your cursor over your keyboard and click Key Assignments. Click the + button in the Assignments section. In Assignment Type, select the action you want to assign. In the Key section, select the key you want to assign the action to. After you have created a key assignment, you can click the menu button next ...
See device configuration policies with Microsoft Intune
For example, the policy updates a setting specific to iOS 11.1, but the device is using iOS 10. Device assignment status shows information for the user that last checked-in. Select Generate report to see the latest policy assignment states for the devices that received the policy. You can also filter the assignment status to see only errors ...
eSIM
eSIM How to assign a preferred mobile plan to contacts. If using dual SIM, dual standby, you can assign a use for each line. To do so, follow these steps: Go to the Home screen. Scroll to the right. Choose Contacts. Choose a contact. Choose the default line, in this case, Primary. Under ALWAYS USE, choose the line you would like to use for ...
Error(18210): LogicLock region assignments cannot be used in Quartus
Programmable Devices CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers Success! Subscription added. ... Error(18210): LogicLock region assignments cannot be used in Quartus Prime Pro Edition. Remove these assignments, or modify them to use LogicLock Plus region assignments.
Discrete Device Assignment
The manufacturer of this device has not supplied any directives for securing this device while exposing it to a virtual machine. Use the "-force" options only with extreme caution, and only when you have some deep knowledge of the device involved. You have been warned. Read the next post in this series: Discrete Device Assignment — GPUs
20 Security Issues Found in Xiaomi Devices
Settings - Binding arbitrary services with system privileges. Settings - Theft of arbitrary files with system privileges. Settings - Implicit broadcasts expose Bluetooth and Wi-Fi data. Settings - Implicit activity intents expose Xiaomi account, Wi-Fi, Bluetooth data, and phone numbers. GetApps - Memory corruption.