App Layering: Error while finalizing a layer version: “Layer volume label does not follow the required format.

App Layering uses the Volume Name for its disks to identify layers by ID number. You must never change the drive names while editing a layer. If you do, you will be unable to finalize the layer version. The package disk will be downloaded, but on analysis, Finalize will fail and you will be sent back to the Packaging Machine to resolve the issue. You can either rename the disk back to what it needs to be, or you can cancel the layer edit and try again.

The filesystem volume name for a Unidesk layer looks like this:

UDiskP<layerId>V0Rx – for instance UDiskP8F0018V0R3

“layerId” is an internal hexadecimal number identifying the layer, but you can get it from the machine name. Run HOSTNAME from the packaging machine, and it’ll be named something like CITRXAL8f0018. Strip off CITRXAL and render that hex number in caps and you have the LayerId. (It also shows up in a few logs and the registry, but HOSTNAME is a cheap way to get it.) What I can’t tell you is the revision number – the “x” in the “Rx” at the end of the name. That’s a sequence number that increases every time you attempt to add a version to a layer, not every time you succeed. So this might be your second revision, but your tenth attempt, and this would be R10 instead of R2. Nowhere in the packaging machine is the revision number stored. Nowhere in the ELM that you can see is the revision number displayed.

However, it turns out that we don’t actually care about the R number. We just require it to be there. So pick one. The layer ID, however, must be correct. If you substitute an incorrect layer ID, Finalize will simply fail further on.

Related:

  • No Related Posts

App Layering/Unidesk: STOP 0x75640007

STOP code 0x75640007 comes from the App Layering filter driver. It specifically means that all of the required layers were not mounted by Windows within 10 minutes. Since those layers should appear instantly when Windows boots up, we assume there is a problem and blue-screen so the system can try again.

The most common reason for Windows to be unable to surface the layer disk is a policy or software that blocks access to removable devices. These policies are usually designed to block access to USB drives to prevent corporate espionage. However, virtual disks from most hypervisors are also set as removable in Windows, which allows the hypervisor to add and remove them without rebooting the guest OS. Technically, both the boot disk and the package disk are removable, but Windows can’t be blocked from accessing its own boot disk. So the policy only blocks access to the package disk, which means App Layering cannot access it. We wait 10 minutes for it to become visible, and then we give up.

The only solutions are to remove the policy (or configure the software to stop that restriction), or figure out how to white-list the extra disks. If this is not possible, contact Support and we can look into software that might be able to change those disks to be non-removable.

Related:

App Layering: Getting AppSense and WebSense to work

Tradução automática

Эта статья была переведена автоматической системой перевода и не был рассмотрен людьми. Citrix обеспечивает автоматический перевод с целью расширения доступа для поддержки контента; Однако, автоматически переведенные статьи могут может содержать ошибки. Citrix не несет ответственности за несоответствия, ошибки, или повреждения, возникшие в результате использования автоматически переведенных статей.

Related:

  • No Related Posts

App Layering: SCCM 2012 Client Recipe

Software Solution Disclaimer

This package contains a software solution that has been replaced by a more recent version available for download from the Citrix support website (support.citrix.com). It is provided merely for your convenience. Citrix recommends applying the most up-to-date version of the software, which addresses the fix or enhancement being targeted. Later versions of the release may include multiple changes that address different areas including security vulnerabilities, code fixes, and enhancements. Installation of this software should only be performed on test or developmental environments. This software is not supported and is provided “AS IS.” You are solely responsible for your selection and use of the software. Any reported issues will require the most current revision of the software (http://www.citrix.com/English/SS/supportThird.asp?slID=5107&tlID=1861652). Please visit our security site for additional security notices and information (support.citrix.com/securitybulletins ).

CITRIX MAKES NO REPRESENTATIONS OR WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE WITH RESPECT TO THE PROVIDED SOFTWARE SOLUTION. THE SOFTWARE SOLUTIONS ARE DELIVERED ON AN “AS IS” BASIS WITH NO SUPPORT. YOU SHALL HAVE THE SOLE RESPONSIBILITY FOR ADEQUATE PROTECTION AND BACK-UP OF ANY DATA USED IN CONNECTION WITH THE SOFTWARE SOLUTION. IN NO EVENT SHALL CITRIX BE LIABLE FOR (i) SPECIAL, INDIRECT, DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, OR (ii) ANY OTHER CLAIM, DEMAND OR DAMAGES WHATSOEVER RESULTING FROM OR ARISING OUT OF OR IN CONNECTION WITH THE SOFTWARE SOLUTION, WHETHER AN ACTION IN CONTRACT OR TORT, INCLUDING NEGLIGENCE, OR OTHERWISE.

Related:

Disabling automatic password change for nonpersistent desktops

Computers use their machine account password for authentication with Active Directory. By default, computers are configured to change their machine account passwords every 30 days. This setting affects nonpersistent desktops in the following ways:

  1. When you deploy the nonpersistent desktop, the pristine snapshot of the desktop contains the original password.
  2. After 30 days, the machine account password automatically changes.
  3. Active Directory accepts the new password for authentication.
  4. When you restart the nonpersistent desktop, it reverts to the pristine snapshot which contains the original password.
  5. Authentication with Active Directory fails because the pristine snapshot does not contain the new machine account password.

If a problem occurs that is related to the password change, users are likely to see an error message similar to the following one when they try to log in to the desktop:

The trust relationship between this workstation and the primary domain failed

Related:

  • No Related Posts

App Layering/Unidesk: The list of Windows Updates is usually wrong in app/platform layers and published images/desktops

The Windows Update history is correct only in the layer where the updates were actually installed. So you can only rely on the displayed list of Windows Updates when you are editing the OS layer, because Windows Updates must always be installed in the OS Layer. Similarly, you can only rely on the list of MS Office updates when editing the Office layer. Looking at any other layer or at any published image, the list of Windows updates is likely to be wrong.

You should ignore the Windows Update history layers and images. The Update history list is just a table of updates that have been applied. The existence or absence of a particular record in that table does not actually reflect the presence of the update itself. Updates replace files in the filesystem, and those files were still replaced.

The table you see in an individual layer is based on the version of the OS layer that the app/platform layer was originally created on. Adding a version to the layer base on a later OS version does not update that list. So when you look at the list of updates in an app/platform layer, you usually see the list from the original version of your OS layer. With Office, you may also see Office updates listed. In the Office layer itself, the Office updates will be correct, since they were installed in the layer, but the Windows updates will not be.

The table you see in a desktop or published image is mostly coming from the last app layer (the most recently created one) or the platform layer. If that layer was made with a previous OS version, it may contain the list of Windows updates from that OS version rather than the current OS or the OS it was last edited with. When the OS is updated, the app layer still has the old table.

If you look at the actual files, though, you will find that the contents of the disk reflect all the Windows updates regardless of that list. Since we strongly recommend never installing Windows Updates in a desktop or app layer, we haven’t made any effort to keep that table intact.

Related:

Instances are in DOWN or ‘OUT OF SERVICE’ state on NetScaler MAS

Tradução automática

Эта статья была переведена автоматической системой перевода и не был рассмотрен людьми. Citrix обеспечивает автоматический перевод с целью расширения доступа для поддержки контента; Однако, автоматически переведенные статьи могут может содержать ошибки. Citrix не несет ответственности за несоответствия, ошибки, или повреждения, возникшие в результате использования автоматически переведенных статей.

Related:

  • No Related Posts

Application Crashes in Desktop Session When Using a Touchscreen Client

Tradução automática

Эта статья была переведена автоматической системой перевода и не был рассмотрен людьми. Citrix обеспечивает автоматический перевод с целью расширения доступа для поддержки контента; Однако, автоматически переведенные статьи могут может содержать ошибки. Citrix не несет ответственности за несоответствия, ошибки, или повреждения, возникшие в результате использования автоматически переведенных статей.

Related:

  • No Related Posts

Error Occurs When Manually Deleting Apps After Removing VPP Account

A VPP account/token was deleted from the XenMobile server configuration, the apps remain there so you try to manually delete the apps one by one.

When you remove the apps manually they get a generic error “A configuration error occurred. Please try again.” with any of the apps associated with that VPP.

Deleting apps error was caused by following exception, found in Support Bundle:

com.citrix.controlpoint.rest.ApplicationResource | Error deleting application

javax.persistence.EntityNotFoundException: No row with the given identifier exists: [com.citrix.xms.entities.AppSettings#2107698]

at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:111) ~[hibernate-core-5.2.7.Final.jar:5.2.7.Final]

at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:155) ~[hibernate-core-5.2.7.Final.jar:5.2.7.Final]

at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:162) ~[hibernate-core-5.2.7.Final.jar:5.2.7.Final]

When checking on the database you also might confirm the data object does exist in database. It seemed this error occurred on hibernation session layer for some reason. You might find as well the same exception is reported for other db tables intermittently.

Related:

  • No Related Posts

Multi-Touch: application crashes in desktop session when using a touchscreen client

Tradução automática

Эта статья была переведена автоматической системой перевода и не был рассмотрен людьми. Citrix обеспечивает автоматический перевод с целью расширения доступа для поддержки контента; Однако, автоматически переведенные статьи могут может содержать ошибки. Citrix не несет ответственности за несоответствия, ошибки, или повреждения, возникшие в результате использования автоматически переведенных статей.

Related:

  • No Related Posts