HID and some other type of USB device fail to redirect

Registry setting DeviceRules on the client computer take precedent over Citrix Studio, AD, and Receiver.admx policies. (The client computer is the computer with Receiver for Windows installed).

Review the registry data on the client computer in the registry setting DeviceRules.

Path: HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeCitrixICA ClientGenericUSB

Name: DeviceRules

Type: REG_MULTI_SZ

Observe that specific devices classes and subclasses are denied in the DeviceRules setting.

If the device class you are attempting to redirect is listed as Deny in the DeviceRules- then create a new entry above the Deny related to device class or place a # in front of the target class / subclass or delete the entry to remove the device rule that is blocking the redirection.

A walkthrough – How to enable Imprivata HDW-IMP-60 device.

Step 1. Review the device on the client computer. Record the class, subclass, VID and PID settings. Open device manager and find the target USB device.

User-added image

The target device has a Class 03 and SubClass 01. Note this matches a DENY rule in the client registry DeviceRules.

User-added image

Modify the DeviceRules registry entry on the client computer (highlighted below). Add an ALLOW rule for the target device above the DENY rule that matches the class and subclass or optionally comment the line with a ‘#’ character …

User-added image

Now create a Client USB device redirection and Client USB device redirection rules policy that applies to the target.

User-added image

Once the policy applies and the client computer registry is modified now the device appears in Device manager as a Generic device. The device is ready for redirection as a generic device.

User-added image

After selecting the Redirect in the Device manager the device is available in the VDA ICA session. Open device manager on the VDA and confirm that the Imprivata HID type device appears in the VDA session- by reviewing the VID and PID of the device.

User-added image

Related:

  • No Related Posts

Configure access control for PMS agent’s folder and registry

I need a solution

As far as I know, PMS Agent does not have its own protection.

So I would like to use SEP to block all access to the Agent-related folders and registry, and allow access only to the Agent process.

Which process should I grant permission(create/modify/delete)?

This is all I know.

the Agent-related folder

– %SystemDrive%Program FilesAltiris*

registry

– HKEY_LOCAL_MACHINESOFTWAREAltiris

– HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeAltiris

– HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionUninstallAltirisAgent

0

Related:

  • No Related Posts

What are the HKLMRSD hives and how are they used in App Layering?

RSD is the App Layering (and Unidesk) registry virtualization system. It stands for Registry Splitter Driver, and allows us to combine multiple registry hives into a single virtual hive for both reads and writes.

The RSD hives are always mounted directly under HKEY_LOCAL_MACHINE, and they are all uniquely named. Normally, it’s RSD_something, where “something” includes the ID of the layer involved. When editing a layer, there will be one RSD hive, and the ID is the layer being edited. That hive is write-only, capturing the data of the boot registry hives as they are being modified. For a published image, there might be multiple RSD hives, however, some of which are read-only, and one of which is read/write. (In Unidesk V2 and V3, there is always only one RSD hive, and the ID is either the layer you are editing or the desktop you are on.) All of the RSD hives, no matter what they are, are stored in C:Program FilesUnidesketc.

Here’s an example of a machine with three RSD hives.

regedit, showing RSD_P1, RSD_VIRTP800007V0R1 and RSD_VIRTPDF8006V0R1

This is from a published machine, which you can tell because it has more than one RSD hive mounted.

There are four kinds of RSD hives.

  • RSD_PxxxV0Ry: when editing an Application or Platform layer, there will be one RSD hive mounted. The “xxx” is the hexadecimal representation of the layer ID (which you can see in the Layering Management Console if you click the (i) for additional information). “y” is the revision number of the layer.
  • RSD_P1: when Elastic Layering is set to Applications Only or Office 365, P1 is the system-wide, temporary RSD hive where local changes are stored and retrieved.
  • RSD_VIRTPxxxV0Ry: with any Elastic Layering mode, this is the RSD hive for an Elastically Assigned layer. “xxx” is the layer ID, and “y” is the revision number. It is read-only, and is attached when the Elastic Layer is attached. The VIRTP hive is the exact same hive that was captured as the P hive when creating a layer.
  • RSD_UepMount: when Full User Layers are selected, this is the read/write hive for the Full User Layer, attached at user login, where all registry writes are captured.

Within each mounted RSD hive, there is one top-level folder called REGISTRY; under that are folders for the specific HKEYs being virtualized, and under that are folders for the hives. So RSD_P1REGISTRYMACHINESystem is the virtualized HKEY_LOCAL_MACHINESystem hive. The RSD hives are not complete registry hives. They contain only the data that has been created, deleted or modified within their respective scopes. For P1 and UepMount, that is data within the current session or for the specific user’s history. For P and VIRTP, those are the data from the creation of the layer.

You will never have RSD_UepMount and RSD_P1 on the same machine, because they are for different Elastic Layering modes. But you can have multiple RSD_VIRTP hives on a machine, one for each attached Elastic Layer.

Within the hives, we capture the exact data being updated. The name, location, data, and security settings are copied into the writable RSD hive exactly as they are being written into the main system registry hives. If you create some key called MyData (DWORD) in HKLMSoftwareMysoftwareWhatever, then we will create the exact same MyData in HKLMRSD_P1REGISTRYMACHINESoftwareMysoftwareWhatever. Th original write still goes to the main hives on the boot disk, but we keep a copy in our own hive.

In addition to capturing new and modified keys, which is easy since it’s just a direct copy of the key, we also need to be able to capture deletions of keys. We do this by deleting the actual key from RSD and replacing it with a slightly modified key. Instead of MyData, we will create a key in the same location (of type REG_NONE) called MyData followed by ASCII 01 through 08. For instance, “MyData”:

RegEdit showing a key with a delete token

In that screen shot, Last Counter and Last Help were created or updated (you can’t actually tell the difference), but Updating was deleted. Whenever you see that set of ASCII graphic charact6ers at the end of a registry key in an RSD hive, it’s not corruption. It’s an indicator that the original key was deleted.

You can also see a __Unidesk_ key above it. Ignore those, they are strictly for internal bookkeeping.

The actual driver that implements our registry virtualization is unirsd.sys. When a request to read a registry key is received, UniRSD intercepts the request and checks with every attached RSD hive to see if the key has been modified anywhere in the system. First it checks the hives on the boot disk, then each of the attached read-only hives, if any, and then it checks the writable hive (RSD_P1, RSD_UepMount or RSD_PxxxV0Ry, depending on what kind of machine is involved). The highest priority copy of the data is used. If the highest priority copy is actually a delete token, then “KeyNotFound” is returned instead. When a request to create, modify or delete a key comes in, it is always routed to the writable hive.

Although seldom appropriate, it is possible to directly modify the writable hive in order to modify the registry. Normally, you would simply modify the main hive, and let UniRSD decide where to route the request. But if you want the writable hive to simply forget a key. which would allow the original version from a lower hive to become visible again, you can manually delete it from the writable hive in RegEdit, and the lower-priority copy will immediately become the highest priority copy, and will become visible.

You can also modify the read-only RSD hive from an attached Elastic Layer, but that change is strictly local and will be dropped on the next reboot.

All of these RSD hives are in C:Program FilesUnidesketc, as we said above. The etc folder, in addition to containing the writable hives and the VIRTP hives from Elastically Assigned layers, actually also includes the RSD_P hives from every layer included in the image itself. These hives are part of their respective layers, so they are include in the published image even though they are not actually used in the published desktop. So, in theory, if you wanted to understand what layer in the published image contained a particular piece of data, you could load up its RSD hive from the published image and look around.

Related:

  • No Related Posts

Error: “Cannot Complete Your Request” Due to File Change Notification of IIS Being Enabled

If you only get the error when accessing the server for first time after an idle time or running an antivirus scan then disable the File Change Notification feature on the IIS server where StoreFront is running.

For .NET 4.0 and Lower

Find app bitness from appPool advance settings.

64 bit: To enable this hotfix, you must add the following DWORD value of 1 at the following registry key:

HKLMSoftwareMicrosoftASP.NETFCNMode

32 bit: If you are running a 32-bit process on an x64-based system, add the following DWORD value of 1 at the following registry key:

HKLMSOFTWAREWow6432NodeMicrosoftASP.NETFCNMode

For .NET 4.5 and Higher

Starting with the Microsoft .NET Framework 4.5 and later versions, FCNMode can be configured by using the httpRuntime settings as follows:

<httpRuntime fcnMode=”Disabled”/>

For more information refer to the following blogs:

ASP.NET File Change Notifications, exactly which files and directories are monitored?

ASP.NET Performance issue: Large number of application restarts due to virus scanning

Related:

  • No Related Posts

Completing Setup after “The Computer Restarted unexpectedly or encountered an unexpected error”

When Windows Setup hits an error and restarts (like if it panics or if you reset it because it appears to have hung), you just get the dreaded “The Computer Restarted unexpectedly or encountered an unexpected error” dialog box which you cannot recover from. Until now:

http://answers.microsoft.com/en-us/windows/forum/windows_7-system/error-message-the-computer-restarted-unexpectedly/b770f14d-e345-e011-90b6-1cc1de79d2e2

Run RegEdit in the machine (after Shift-F10 to get the CMD window).

HKLM/SYSTEM/SETUP/STATUS/ChildCompletion

Check for setup.exe on the right, and if the value is 1 change it to 3. Then close RegEdit and click the button to reboot again. This may allow Setup tom complete and get you a more functional Windows than you can get from Shift-F10.

Related:

  • No Related Posts

Can’t Uninstall Symantec for Windows 10 Upgrade (version 1803)

I do not need a solution (just sharing information)

I just wanted to share what I think will be helpful information related to the commonly experienced error preventing Windows 10’s latest upgrade (version 1803) related to uninstalling Symantec. In my case, I had never installed it in the first place. Another user gave some great information in this post:

https://www.symantec.com/connect/forums/solved-win…

However, it can be difficult to find the exact path of the offending files. I discovered a registery key that gives the answer.

Try looking in your registry under:

ComputerHKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionAppCompatFlagsUpgradeCompatibilityTemp

Any key under that path will have a string value called “ExeFullPath” which should point you to the files that need to be removed. At least, it worked for me.

I hope that helps!

0

Related:

  • No Related Posts

7022957: ZAPP.exe startup values removed by Windows 10 1803 Upgrade

This document (7022957) is provided subject to the disclaimer at the end of this document.

Environment

ZENworks Configuration Management 2017

Situation

The ZAPP reference in the Windows “Run” registry key gets removed during a Windows 10 1803 Feature Upgrade if the reference to ZAPP-Launcher.exe is not the full literal path without the use of any variables.

Resolution

Update the “ZAPP” registry key to use a full literal path prior to upgrade or restore the value after upgrade.

Citrix Receiver Updates Troubleshooting Guide

For information about configuring Receiver Updates, see Configuring Receiver Updates in Citrix product documentation.

Update: Citrix Receiver for Mac 12.9.1 contains the fix for Auto Update.

Note: Review CTX234657 to resume Auto Update and fix the “Problem Checking for updates” error displayed in Citrix Receiver Updater.

There are three sections in this document:

Section 1: Key Citrix Receiver Updates settings for troubleshooting

Section 2: Citrix Receiver Updates Logging

Section 3: Troubleshooting Citrix Receiver Updates

Section 1: Key Citrix Receiver Updates settings for troubleshooting

You can configure Citrix Receiver Updates as follows:

  1. Right-click the Citrix Receiver for Windows icon in the notification area.
  2. Select Advanced Preferences, and click Auto Update. The Citrix Receiver Updates dialog appears.

By default, the Yes, notify me option is enabled.

User-added image

If an administrator manages the user account or if an user is under a company policy, the Receiver Updates options might be set according to the administrator-specified settings.

This is the only setting for Citrix Receiver Updates that is available for an end-user modification.

Citrix Receiver Updates rollout period:

Citrix Receiver Updates rollout do not happen to all users on same day or at the same time. It depends on the delivery period and delay groups. Ideally delivery period is 30 days. So, users will get Receiver and related plug-ins updates any day between Day-01 and Day-30.

Based on the delay group settings, updates are available at the beginning, the middle, or the end of the delivery period.

The delay groups are categorized as follows:

  1. Fast – Update rollout happens at the beginning of delivery period.
  2. Medium – Update rollout happens at mid-delivery period.
  3. Slow – Update rollout happens at the end of delivery period.

Citrix Receiver Updates can be configured to deliver only updates marked for Long Term Support Releases (LTSR) or Current Releases (CR). The default is to accept CR updates.

These settings can be configured during Citrix Receiver for Windows installation, or using the Group Policy Object administrative template, or the StoreFront Account.

The registry location for each of these methods is:

  1. Install Time: HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeCitrixICA ClientAutoUpdateCommandline Policy
  2. GPO: HKEY_LOCAL_MACHINESOFTWARE[WOW6432Node]PoliciesCitrixICA ClientAutoUpdate
  3. StoreFront: HKEY_CURRENT_USERSOFTWARECitrixReceiverSRStore<some random number>Properties

The relevant registry values to examine are:

For Install Time and GPO configured settings

Value: Auto-Update-Check

possible data:

Auto” (default) – perform auto updates,

Manual” – updates are only fetched when the user makes a check request from the Receiver menu,

Disabled” – no updates checks will be made.

Value : Auto-Update-LTSR-Only

possible data:

True” – the updater will ignore any updates that are not marked as being LTSR valid,

False” (default) – the updater will accept any updates.

Value : Auto-Update-Rollout-Priority

possible data:

Fast” – updates will be accepted towards the beginning of the delivery period,

Medium” – updates will be accepted towards the middle of the delivery period,

Slow”– updates will be accepted towards the end of the delivery period.

For StoreFront Account configured settings

Value: Enable

possible data:

True” (default) – perform auto updates,

False” – updates are only fetched when the user makes a check request from the Receiver menu

Value : LTSROnly

possible data:

True” – the updater will ignore any updates that are not marked as being LTSR valid

False” (default) – the updater will accept any updates.

Value : BucketId

possible data:

Fast” – updates will be accepted towards the beginning of the delivery period,

Medium” – updates will be accepted towards the middle of the delivery period,

Slow” – updates will be accepted towards the end of the delivery period.

Section 2: Citrix Receiver Updates Logging

Before you troubleshoot any issues with the Citrix Receiver Updates functionality, enable logging for Citrix Receiver Updates.

In Citrix Receiver for Windows Version 4.9, Citrix Receiver Updates logging is disabled by default.

In Citrix Receiver for Windows Version 4.8, Citrix Receiver Updates logging is enabled by default.

Citrix Receiver Updates logs can be found at /%temp%/<CitrixAutoUpdate _.log>

To enable Citrix Receiver Updates logging using the registry editor:

  1. Launch the registry editor.

  2. Navigate to HKEY_LOCAL_MACHINESOFTWARECITRIX.

    Note: If you are an individual user, navigate to HKEY_CURRENT_USER SOFTWARECitrix.

  3. Add a new DWORD value.

    On 32-bit systems:

    HKEY_LOCAL_MACHINESOFTWARECitrix

    Name: AutoUpdateTracingEnabled

    Type: REG_DWORD

    Data: 1

    On 64-bit systems: HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrix

    Name: AutoUpdateTracingEnabled

    Type: REG_DWORD

    Data: 1

  4. Save and close the registry editor.

  5. Restart the Citrix Receiver for Windows session for the changes to take effect.

Section 3: Troubleshooting Citrix Receiver Updates

Check for the requirements below as part of troubleshooting Citrix Receiver Updates.

  1. If you have configured an SSL intercepting outbound proxy, you must add an exception to the Receiver Citrix Receiver Updates Signature service (https://citrixupdates.cloud.com) and the download location (https://downloadplugins.citrix.com).
  2. If the Receiver for Windows session is running on a VDA, Citrix Receiver Updates is disabled.
  3. If the Receiver for Windows is running on an end-point where the Desktop Lock component is enabled, Citrix Receiver Updates is disabled.
  4. In Citrix Receiver for Windows Version 4.8, Citrix Receiver Updates was not functioning in a proxy setup. This issue has been addressed in Version 4.9.
  5. The Citrix Receiver Updates functionality is not available when a user with administrator-level privileges has installed Citrix Receiver for Windows, and an individual user(non-admin) is accessing Citrix Receiver for Windows.

Common issue #1: Software is up-to-date:

To check for updates manually, select the Check for Updates option from the Citrix Receiver for Windows icon in the notification area. When you check for updates manually and do not find any update available, it is due to one of the following reasons:

  1. No updates are available.
  2. Your account is set to a medium or slow category in the delay group. This indicates that the update rollout happens at the middle or at the end of the delivery period.

The following dialog appears when you check for updates manually and when no updates are available.

User-added image

Solution:

You can check for updates at a later time or wait for the Citrix Receiver Updates notification.

Common issue #2: Issue when checking for update:

An update check can fail for various reasons. For example:

  1. No network connection during update check.
  2. Firewall settings don’t allow the connection to update server.

The following error message appears if there is an issue when checking for update.

User-added image

Solution:

Ensure that your network connection is working properly. Alternatively, also verify that the firewall settings are not blocking the connection to Citrix update server.

Common issue #3: Issue when downloading the update

There is a network connection issue when checking for update or when you click the Download option.

The following error message appears if there is an issue when downloading the update.

User-added image

Solution:

Ensure that your network connection is working properly.

Common issue #4: Error during installation:

During update installation, the following issues might occur:

  1. Not enough disk space
  2. During installation, if the operating system starts with any other installation, Citrix Receiver installation turns unresponsive and the update installation fails.

The following error message appears if the Receiver Update install occurs at the same time as another install on the system.

User-added image

Additional Resources:

Resume auto-update for Citrix Receiver

Receiver for Mac Auto-Update Troubleshooting Guide

Citrix Receiver Auto-Update Frequently Asked Questions

Related:

  • No Related Posts

7022379: ZENworks Passive Mode login fails after reboot or shutdown/restart on Windows 10 with Fall Creators Update due to ARSO changes

This document (7022379) is provided subject to the disclaimer at the end of this document.

Environment

ZENworks Configuration Management 11.4

ZENworks Configuration Management 2017

Situation

On Windows 10 with Fall Creators Update (Build 1709) managed devices, users will not be logged in passively after reboot or shutdown and restart of the device due to Winlogon Automatic Restart Sign-On (ARSO) set as default for user startup.

NOTE: This TID is about ARSO issue. For failure to login passively after Windows OS upgrade due to provider registry keys removed, unrelated to ARSO, see also http://novell.com/support/kb/doc.php?id=7022478
NOTE: This TID also applies to the Windows 10 April 2018 Update (Build 1803)

Resolution

Workaround: Disable ARSO via registry or group policy. If not using a policy, a registry bundle can be made to set the registry and assigned to devices.

Policy location:
Computer Configuration > Administrative Templates > Windows Components > Windows Logon Option
Policy Name: Sign-in last interactive user automatically after a system-initiated restart
need to set “Disabled

Registry Location:
HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem

Registry Name: DisableAutomaticRestartSignOn
Type: DWORD set to 1

Cause

ARSO bypasses the third party credential providers by design.

Status

Reported to Engineering

Additional Information

For more information see https://social.technet.microsoft.com/Forums/en-US/efc99b56-8f1f-4364-b081-0b6db46e9dda/global-policy-for-new-use-my-signin-info-to-automatically-finish-setting-up-my-device-after-an?forum=WindowsInsiderPreview

The Information Below is provided as courtesy.
Information Posted on the “Cool Solutions Site” and the Support Forums are not officially supported.
The Windows 1709 Feature Update can be deployed by a ZCM Bundle. (Note: ZPM is not required and the Content-Repo can be used in lieu of installing from a share if desired.)
See – https://www.novell.com/communities/coolsolutions/deploying-windows-10-feature-updates-via-zenworks-patch-management/

Related:

  • No Related Posts