Target device fails to boot with “vDisk is locked. 0xffff800c”

When a target device boots up with the assigned vdisk, a lock gets created on that vdisk. The locked vDisk icon appears with a small lock on it.

Under certain circumstances the locks are not released properly. In cases where a target device tries and fails to boot with a specific vdisk, the locks do not get released properly. If the same target device boots again, the same lock is used and no problem occurs.

Related:

  • No Related Posts

Cisco IOS XR Software Enhanced Preboot eXecution Environment Unsigned Code Execution Vulnerability

A vulnerability in the enhanced Preboot eXecution Environment (PXE) boot loader for Cisco IOS XR 64-bit Software could allow an unauthenticated, remote attacker to execute unsigned code during the PXE boot process on an affected device. The PXE boot loader is part of the BIOS and runs over the management interface of hardware platforms that are running Cisco IOS XR Software only.

The vulnerability exists because internal commands that are issued when the PXE network boot process is loading a software image are not properly verified. An attacker could exploit this vulnerability by compromising the PXE boot server and replacing a valid software image with a malicious one. Alternatively, the attacker could impersonate the PXE boot server and send a PXE boot reply with a malicious file. A successful exploit could allow the attacker to execute unsigned code on the affected device.

Note: To fix this vulnerability, both the Cisco IOS XR Software and the BIOS must be upgraded. The BIOS code is included in Cisco IOS XR Software but might require additional installation steps. For further information, see the Fixed Software section of this advisory.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-pxe-unsign-code-exec-qAa78fD2

Security Impact Rating: High

CVE: CVE-2020-3284

Related:

  • No Related Posts

Citrix Provisioning Target Device Boot Failure “Error: “Status 0xc000000e. A required device isn't connect or can't be accessed “

While booting a physical Target Device the Target fails with a BSOD:

“Status 0xc000000e. A required device isn’t connected or can’t be accessed”

Although the physical device from which the vDisk was created does boot without error, all subsequent Targets fail.

Related:

Debugging Layer Integrity Problems in Citrix App Layering 4.x and later

In V4, when you’re ready to shutdown and finalize a layer, you run the Shutdown for Finalize icon on the desktop (As Administrator). It makes a call to uniservice.exe to get the current Layer Integrity state. Uniservice is tracking all the same things it always has for Layer Integrity: NGEN or MSCORLIB is still running, a reboot is pending, a domain operation is still pending, or a RunOnce script is still waiting.

Shutdown for Finalize is checking to see if anything is still pending that should happen in the layer rather than happen in the image later. If something is, it does not shut down, and instead puts up a statement about the pending issue. Fix the issue (for instance, reboot) and try again. It also writes this information into two log files:

C:Program FilesUnideskUniserviceLogLayerIntegrity.txt

C:Program FilesUnideskUniserviceLogUniBilcLogs_X.txt

You can’t know exactly which UniBilcLogs file it’s using, so look for the one with the latest timestamp. That will be for the current boot. Search for “Integrity”.

You might think you could bypass the Layer Integrity check by just shutting down the machine normally and finalizing that. But if you try, you will find the ELM will stop the task and return you to the Packaging Machine, because it knows that the Layer Integrity Checks either failed or never ran. You must successfully run that Shutdown for Finalize script to finalize a layer.

The registry key, noted at the end of this article, to bypass or ignore integrity problems still works, and you should be just as reluctant to use it as ever. But it’s still a valid way to give up and bypass it.

There are 7 Layer Integrity warnings you can see:

“a RunOnce script is outstanding – please check and reboot the Packaging Machine”

“a post-installation reboot is pending – please check and reboot the Packaging Machine”

“a Microsoft NGen operation is in progress in the background {0}”

“an MSI install operation is in progress – please check the Packaging Machine”

“a reboot is pending to update drivers on the boot disk – please check and reboot the Packaging Machine”

“a Microsoft NGen operation is needed”

“Software Center Client is configured to run, but the SMSCFG.INI is still present. See https://social.technet.microsoft.com/wiki/contents/articles/23923.implementing-sccm-in-a-xendesktop-vdi-environment.aspx”

“A RunOnce script is outstanding” is telling you that there is a key in either of these two locations:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnce

HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRunOnce

Windows normally deletes those keys on reboot, but we have seen circumstances (especially with our own script, envsetup.cmd) where that doesn’t happen. You can manually run the referenced script and delete the key, or just delete the key if the script file no longer exists.

“A post-installation reboot is pending” is looking at six different registry keys. Your first course of action should be to reboot, more than once(in some cases it has taken 3+ reboots), just to make sure that it isn’t a real reboot being requested by some software. It may also be helpful, if the problem is NetLogon, to restart the Unidesk Service for Message Management.

First we check for the existence of any of these three:

HKLMSystemCurrentControlSetControlSession ManagerPendingFileRenameOperations

HKLMSOFTWAREMicrosoftWindowsCurrentVersionComponent Based ServicingRebootPending

HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAuto UpdateRebootRequired

You can manually modify any of these to suit your needs, including just deleting them.

Then we look for changes in the NetLogon key (if the current value is now different from what it was at bootup), and to see if the computer name doesn’t match the active computer name. This is how we determine that a domain-join operation is still waiting for a reboot.

HKLMSYSTEMCURRENTCONTROLSETSERVICESNETLOGONStart

HKLMSYSTEMCURRENTCONTROLSETCONTROLCOMPUTERNAMEACTIVECOMPUTERNAME

HKLMSYSTEMCURRENTCONTROLSETCONTROLCOMPUTERNAMECOMPUTERNAME

Generally you cannot modify these. I’ve seen some software modify the NETLOGONStart key on every reboot, so maybe that’s happening. If, after cleaning out the top three, you still get the prompt on reboot, you will need to use the flag to ignore layer integrity checks.

“A Microsoft NGen operation is in progress in the background” is telling you that a foreground or background NGEN operation (where .Net assemblies are compiled into native images) is still in progress. Generally this is simply true: the ngen rebuild is still running. To watch it in the foreground, run “ngen update /force”. Or you can wait it out, and run “ngen queue status” periodically to see how it’s doing, but that will slow it down because the background process pauses every time you check its status in the foreground. Don’t reboot or you might cause it to have to start over.

It’s important to let NGEN finish. If you kill the process or reboot in the middle, you might wind up with partially written .Net assemblies that crash programs when they show up in an image. You should be patient. However, sometimes we have seen background MSCORSVW.EXE processes, clearly doing nothing, that just don’t finish even after hours. A reboot might help those.

We are looking for the following services in the running process: ngen.exe, ngentask.exe, mscorsvw.exe.

“An MSI install operation is in progress” is very specific: it is saying that a system mutex (mutual exclusion object) named precisely Global_MSIExecute exists. The MSI installer uses that to ensure that only one installer can run at a time. I don’t know of anything you can do about this manually, if you are certain that no MSI installations are happening.

(Note, there was in App Layering 4.2 a bug with upgrading an existing Windows 10 layer from 1611 to 1703 where this flag could be set and not cleared.)

“A reboot is pending to update drivers on the boot disk” is telling you that a service or driver that is set to start at system boot time (the START= value in the registry is 0) was modified or installed, and App Layering wants to make sure the modified driver can boot successfully. Normally you just need to reboot once, and the driver will work fine. We have on some occasions seen software (like Microsoft Defender) attempt to modify its driver file on every single boot, triggering this integrity check every time, so no number of reboots is sufficient to clear it.

“a Microsoft NGen operation is needed” is telling you that an application was installed on the packaging machine and that it scheduled items to be updated at a priority level of 3. That means that the ngen will run when idle and that it is simply waiting until there is no more activity. We are blocking because the ngen needs to create the binaries now instead of on every machine that the application will be deployed to in order to ensure that the application will run in the most optimal way. You should run an ngen eqi 3 in both the c:windowsmicrosoft.netframeworkv4.0.30319 directory and the c:windowsmicrosoft.netframework64v4.0.30319 dirctory to have the ngen complete the operations that are needed. You can also wait, as the ngen will typically pick up and run on its own after 15 minutes of idle time.

The values that is being examined are HKLMSOFTWAREMicrosoft.NETFrameworkv2.0.50727NGenServiceRootsWorkPending and HKLMSOFTWAREWOW6432NodeMicrosoft.NETFrameworkv2.0.50727NGenServiceRootsWorkPending. A value of 1 means that there are work items queued up to be processed.

“Software Center Client is configured to run, but the SMSCFG.INI is still present….” is telling you that we have seen that this machine has ccmexec.exe configured as a service and that it is not configured as disabled. Since we know that any layers created on a packaging machine need to be sealed properly in order to deploy correctly in a VDI environment, we are checking to make sure the SMSCFG.ini is not present. See the web page indicated to get an understanding of why the software center client needs to be sealed. We have provided the commands to run in a batch command file that you can use to seal the layer (run c:windowssetupscriptsSEALSCCMCLIENT.cmd for an administrator command window).

If you have a layer that simply won’t ever get to finalize, for whatever reason (like it always thinks it still has a reboot pending, or you don’t care about corrupted .NET assemblies and don’t want to wait for NGEN to finish), you can tell that single layer to ignore its layer integrity checks and allow you tin shutdown to finalize, using a registry key.

Run regedit.exe and create this key

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesUniservice:]

“BypassLayerCheck”=DWORD 1

The value doesn’t matter, all that matters is that the value exists. This will block all layer integrity checks and allow a layer to be finalized regardless as to how bad we think it might be.

Please do not use this key except as a last resort. We block you from finalizing in these 4 circumstances specifically because we believe allowing you to finalize will irreparably harm the layer and/or the image you publish with it. Always try to solve the problem within Windows first.

Related:

Dell Technologies Bolsters PC Security for Today’s Remote Workers

Cybercriminals are opportunistic by nature, altering their attack methods to compromise endpoints and access critical data. This is never truer than during times of change such as now with the overnight shift to a global remote workforce. With cybercriminals ramping up activity, organizations need to protect their remote workers starting with the devices they use to get their jobs done. One area attackers will target is the PC BIOS, the core system built deep inside the PC that controls critical operations like booting the PC and ensuring a secure configuration. To protect against BIOS attacks, organizations … READ MORE

Related:

Citrix Cloud Connector servers are in reboot loop after new update was pushed


There are some locations on operating system where it stores flag for pending reboot:

Look for presence of ‘PendingFileRenameOperations‘ inside following key:

HKLM:SYSTEMCurrentControlSetControlSession Manager

Look for presence of key ‘RebootPending‘ as below:

HKLM:SoftwareMicrosoftWindowsCurrentVersionComponent Based ServicingRebootPending

Look for presence of key ‘RebootRequired‘ as below:

HKLM:SOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAuto UpdateRebootRequired

Most of these flags will be cleared with first reboot of operating system.

But in some special cases, ‘PendingFileRenameOperations‘ would continue to remain inside HKLM:SYSTEMCurrentControlSetControlSession Manager even after reboot.

The value ‘PendingFileRenameOperations‘ stores the names of files that the operating system will rename when it restarts. The key consists of pairs of file names. The operating system renames the file in the first item of the pair to match the second item of the pair.

In such cases, we should check for the value data of ‘PendingFileRenameOperations‘ from registry to identify the files that are pending for rename. Once we know the application responsible for those files (mostly a 3rd party application), follow below steps:

  1. Disable ‘Citrix Cloud Services Agent WatchDog’ to stop the reboot loop temporarily.
  2. Disable the identified applications service(s) OR uninstall the application completely.
  3. Delete ‘PendingFileRenameOperations’ from HKLM:SYSTEMCurrentControlSetControlSession Manager
  4. Reboot the service manually and confirm ‘PendingFileRenameOperations’ doesn’t appear any more inside HKLM:SYSTEMCurrentControlSetControlSession Manager
  5. Enable ‘Citrix Cloud Services Agent WatchDog’ to automatic and start the service.

The pending connector update will begin in few minutes and run a health check from console after the upgrade to ensure it is healthy.

Related:

Multiple Cisco UCS-Based Products UEFI Secure Boot Bypass Vulnerability

A vulnerability in the firmware of the Cisco UCS C-Series Rack Servers could allow an authenticated, physical attacker to bypass Unified Extensible Firmware Interface (UEFI) Secure Boot validation checks and load a compromised software image on an affected device.

The vulnerability is due to improper validation of the server firmware upgrade images. An attacker could exploit this vulnerability by installing a server firmware version that would allow the attacker to disable UEFI Secure Boot. A successful exploit could allow the attacker to bypass the signature validation checks that are done by UEFI Secure Boot technology and load a compromised software image on the affected device. A compromised software image is any software image that has not been digitally signed by Cisco.

There are no workarounds that address this vulnerability. Cisco has released firmware updates that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200219-ucs-boot-bypass

Security Impact Rating: High

CVE: CVE-2019-1736

Related:

  • No Related Posts

Debugging Layer Integrity Problems in Citrix App Layering 4.x

In V4, when you’re ready to shutdown and finalize a layer, you run the Shutdown for Finalize icon on the desktop (As Administrator). It makes a call to uniservice.exe to get the current Layer Integrity state. Uniservice is tracking all the same things it always has for Layer Integrity: NGEN or MSCORLIB is still running, a reboot is pending, a domain operation is still pending, or a RunOnce script is still waiting.

Shutdown for Finalize is checking to see if anything is still pending that should happen in the layer rather than happen in the image later. If something is, it does not shut down, and instead puts up a statement about the pending issue. Fix the issue (for instance, reboot) and try again. It also writes this information into two log files:

C:Program FilesUnideskUniserviceLogLayerIntegrity.txt

C:Program FilesUnideskUniserviceLogUniBilcLogs_X.txt

You can’t know exactly which UniBilcLogs file it’s using, so look for the one with the latest timestamp. That will be for the current boot. Search for “Integrity”.

You might think you could bypass the Layer Integrity check by just shutting down the machine normally and finalizing that. But if you try, you will find the ELM will stop the task and return you to the Packaging Machine, because it knows that the Layer Integrity Checks either failed or never ran. You must successfully run that Shutdown for Finalize script to finalize a layer.

The registry key, noted at the end of this article, to bypass or ignore integrity problems still works, and you should be just as reluctant to use it as ever. But it’s still a valid way to give up and bypass it.

There are 7 Layer Integrity warnings you can see:

“a RunOnce script is outstanding – please check and reboot the Packaging Machine”

“a post-installation reboot is pending – please check and reboot the Packaging Machine”

“a Microsoft NGen operation is in progress in the background {0}”

“an MSI install operation is in progress – please check the Packaging Machine”

“a reboot is pending to update drivers on the boot disk – please check and reboot the Packaging Machine”

“a Microsoft NGen operation is needed”

“Software Center Client is configured to run, but the SMSCFG.INI is still present. See https://social.technet.microsoft.com/wiki/contents/articles/23923.implementing-sccm-in-a-xendesktop-vdi-environment.aspx”

“A RunOnce script is outstanding” is telling you that there is a key in either of these two locations:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnce

HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRunOnce

Windows normally deletes those keys on reboot, but we have seen circumstances (especially with our own script, envsetup.cmd) where that doesn’t happen. You can manually run the referenced script and delete the key, or just delete the key if the script file no longer exists.

“A post-installation reboot is pending” is looking at six different registry keys. Your first course of action should be to reboot, more than once(in some cases it has taken 3+ reboots), just to make sure that it isn’t a real reboot being requested by some software. It may also be helpful, if the problem is NetLogon, to restart the Unidesk Service for Message Management.

First we check for the existence of any of these three:

HKLMSystemCurrentControlSetControlSession ManagerPendingFileRenameOperations

HKLMSOFTWAREMicrosoftWindowsCurrentVersionComponent Based ServicingRebootPending

HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAuto UpdateRebootRequired

You can manually modify any of these to suit your needs, including just deleting them.

Then we look for changes in the NetLogon key (if the current value is now different from what it was at bootup), and to see if the computer name doesn’t match the active computer name. This is how we determine that a domain-join operation is still waiting for a reboot.

HKLMSYSTEMCURRENTCONTROLSETSERVICESNETLOGONStart

HKLMSYSTEMCURRENTCONTROLSETCONTROLCOMPUTERNAMEACTIVECOMPUTERNAME

HKLMSYSTEMCURRENTCONTROLSETCONTROLCOMPUTERNAMECOMPUTERNAME

Generally you cannot modify these. I’ve seen some software modify the NETLOGONStart key on every reboot, so maybe that’s happening. If, after cleaning out the top three, you still get the prompt on reboot, you will need to use the flag to ignore layer integrity checks.

“A Microsoft NGen operation is in progress in the background” is telling you that a foreground or background NGEN operation (where .Net assemblies are compiled into native images) is still in progress. Generally this is simply true: the ngen rebuild is still running. To watch it in the foreground, run “ngen update /force”. Or you can wait it out, and run “ngen queue status” periodically to see how it’s doing, but that will slow it down because the background process pauses every time you check its status in the foreground. Don’t reboot or you might cause it to have to start over.

It’s important to let NGEN finish. If you kill the process or reboot in the middle, you might wind up with partially written .Net assemblies that crash programs when they show up in an image. You should be patient. However, sometimes we have seen background MSCORSVW.EXE processes, clearly doing nothing, that just don’t finish even after hours. A reboot might help those.

We are looking for the following services in the running process: ngen.exe, ngentask.exe, mscorsvw.exe.

“An MSI install operation is in progress” is very specific: it is saying that a system mutex (mutual exclusion object) named precisely Global_MSIExecute exists. The MSI installer uses that to ensure that only one installer can run at a time. I don’t know of anything you can do about this manually, if you are certain that no MSI installations are happening.

(Note, there was in App Layering 4.2 a bug with upgrading an existing Windows 10 layer from 1611 to 1703 where this flag could be set and not cleared.)

“A reboot is pending to update drivers on the boot disk” is telling you that a service or driver that is set to start at system boot time (the START= value in the registry is 0) was modified or installed, and App Layering wants to make sure the modified driver can boot successfully. Normally you just need to reboot once, and the driver will work fine. We have on some occasions seen software (like Microsoft Defender) attempt to modify its driver file on every single boot, triggering this integrity check every time, so no number of reboots is sufficient to clear it.

“a Microsoft NGen operation is needed” is telling you that an application was installed on the packaging machine and that it scheduled items to be updated at a priority level of 3. That means that the ngen will run when idle and that it is simply waiting until there is no more activity. We are blocking because the ngen needs to create the binaries now instead of on every machine that the application will be deployed to in order to ensure that the application will run in the most optimal way. You should run an ngen eqi 3 in both the c:windowsmicrosoft.netframeworkv4.0.30319 directory and the c:windowsmicrosoft.netframework64v4.0.30319 dirctory to have the ngen complete the operations that are needed. You can also wait, as the ngen will typically pick up and run on its own after 15 minutes of idle time.

The values that is being examined are HKLMSOFTWAREMicrosoft.NETFrameworkv2.0.50727NGenServiceRootsWorkPending and HKLMSOFTWAREWOW6432NodeMicrosoft.NETFrameworkv2.0.50727NGenServiceRootsWorkPending. A value of 1 means that there are work items queued up to be processed.

“Software Center Client is configured to run, but the SMSCFG.INI is still present….” is telling you that we have seen that this machine has ccmexec.exe configured as a service and that it is not configured as disabled. Since we know that any layers created on a packaging machine need to be sealed properly in order to deploy correctly in a VDI environment, we are checking to make sure the SMSCFG.ini is not present. See the web page indicated to get an understanding of why the software center client needs to be sealed. We have provided the commands to run in a batch command file that you can use to seal the layer (run c:windowssetupscriptsSEALSCCMCLIENT.cmd for an administrator command window).

If you have a layer that simply won’t ever get to finalize, for whatever reason (like it always thinks it still has a reboot pending, or you don’t care about corrupted .NET assemblies and don’t want to wait for NGEN to finish), you can tell that single layer to ignore its layer integrity checks and allow you tin shutdown to finalize, using a registry key.

Run regedit.exe and create this key

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesUniservice:]

“BypassLayerCheck”=DWORD 1

The value doesn’t matter, all that matters is that the value exists. This will block all layer integrity checks and allow a layer to be finalized regardless as to how bad we think it might be.

Please do not use this key except as a last resort. We block you from finalizing in these 4 circumstances specifically because we believe allowing you to finalize will irreparably harm the layer and/or the image you publish with it. Always try to solve the problem within Windows first.

Related:

Hard Drive in Multicast

I do not need a solution (just sharing information)

I’m trying to create an image using multicast with just the standard tools. I have formated a flash drive with a gpt partition and can get ghost to boot. The issue occurs when I connect to my session using multicast. All I can see is the OS Volume which I know is not my hard drive. On all new Dell’s their is no option for legacy boot. I use to be able to turn the legacy boot options on and see the hard drive, now I can’t when the flash drive boots uefi. This image is a gpt UEFI formatted image for Windows 10. Does anyone have any ideas? I’m grasping at straws.

0

Related: