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

7022478: Zenworks Passive Mode login stops working after upgrade to Windows v1709 or v1803

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

Environment

ZENworks Configuration Management 11.4
ZENworks Configuration Management 2017

Situation

After upgrading the device to Windows 10 v1709 (Fall Creator Update) or Windows 10 v1803 (April 2018 Update) Passive Mode login to Zenworks no longer occurs.

Resolution

1. As suggested by Microsoft in
https://support.microsoft.com/en-in/help/4013822/network-provider-settings-are-removed-during-an-in-place-upgrade-to-wi

backup the following registry keys before the upgrade and restore the keys after the upgrade

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlNetworkProviderOrder

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesZenCredManagernetworkprovider

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsNTCurrentVersionWinlogonNotifyZenCredManager

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLCredMgrnetworkprovider

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonNotifyLCredMgr

Please note that these keys may be device specific so that the backup of one device may not be applicable to others.

2. Use Zenworks Control Center to uninstall and reinstall the UserManagement spoke for the affected devices.

3. Run
(example for a 17.1 device)
msiexec /fvam <PATH>novell-zenworks-usermanagement-17.1.0.1342.x86_64.msi
to re-populate the needed registry keys
Please note that 1. the msi must correspond with the installed ZCM version, 2. the msi must be copied first to the device, 3. the msiexec command has to be run as ‘Administrator’ and 4. a reboot is required for the change to take effect.

Cause

Network provider settings are removed during an in-place upgrade to Windows 10 Version 1607
https://support.microsoft.com/en-in/help/4013822/network-provider-settings-are-removed-during-an-in-place-upgrade-to-wi

Status

Reported to Engineering

Additional Information

The exact conditions on when it may or may not occur are not fully known since it is the Windows Update, not ZENworks Code, that is removing these keys.
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

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

7001124: Logging debug information for SecureLogin.

With logging enabled, NSL will create a file called ssodebug.txt in the following directories:

– on XP workstations: C:Documents and Settings<USERNAME>Application DataSecureLoginLogs,” where USERNAME is the name of the local user on the workstation.

– on Windows 7 workstations: C:Users<USERNAME>AppDataRoamingSecureLoginLogs where USERNAME is the name of the local user on the workstation.
There are two ways to capture NSL debug logs. Both require that SecureLogin be stopped and restarted for changes to take effect.
Method 1. Through the utility SLLoggingManager.exe included with the NSL distriubtion package and found in the directory SecureLoginToolsUnsupported. This is a graphical utility that allows you to configure logging with a few mouse clicks. After launching the utility, just click in the “logging level” field for the desired modules, hit the down arrow and select the desired logging level. If Novell Support has asked you for a NSL log, you will need to select “debug” level.

Method 2. By manually editing the registry to specify the modules to log . Edit the following registry key:

[HKEY_LOCAL_MACHINESoftwareProtocomSecureLogin]

First create the key “Logging,” then create the dword entries from the information below. (Remember to turn the diagnostics log file off once you have finished or the log file will continue to grow and may cause SecureLogin to run slowly.) For example the edited registry will look like this if you select to log for everything:

To instruct SecureLogin to output advanced debug information to the log file, create one or more of the following dword registry entries. Create the registry entry for the specific area in which you want SecureLogin to perform a debug trace.

Each dword entry relates closely to the files of the same or similar name;

[HKEY_LOCAL_MACHINESOFTWAREProtocomSecureLoginLogging]

“All” =dword:00000000

“Allint”=dword:00000000

“Broker”=dword:00000000

“BrokerInt”=dword:00000000

“Launcher”=dword:00000000

“MadMan”=dword:00000000

“SLCredMan”=dword:00000000

“WinLib”=dword:00000000

“NetscapeSSO”=dword:00000000

“WebSSO”=dword:00000000

“WinSSO”=dword:00000000

“Wizard”=dword:00000000

“LotusSSO”=dword:00000000

“Parser”=dword:00000000

“JavaSSO”=dword:00000000

“JavaSSOBHO”=dword:00000000

“AWS”=dword:00000000

“IESSO”=dword:00000000

“XMLConv”=dword:00000000

“TLaunch”=dword:00000000

The values can be set from 0 to 3.

0 means log all messages and 3 logs critical issues only.

The following explains the type of information that each option will log.

“Broker”=dword:00000000

Logs high level information relating to SLBroker.Exe, such as communications and synchronization of SecureLogin data (such as the user’s secrets) with the Directory.

“BrokerInt”=dword:00000000

Logs low level information relating to SLBroker.Exe, including coding symbols and functions.

“Launcher”=dword:00000000

Logs information relating to SLLauncher.Exe, including published applications in a Citrix environment.

“MadMan”=dword:00000000

Logs information relating to MadMan.DLL, including binding user defaults, and setting preferences in a Microsoft Active Directory environment.

“SLCredMan”=dword:00000000

Logs information relating to whether SecureLogin is able to retrieve the user’s ADS username and password in a Microsoft ADS environment.

“WinLib”=dword:00000000

Logs information on SecureLogin’s interaction with the common windows library.

“NetscapeSSO”=dword:00000000

Logs information relating to Single Sign-on to Netscape applications.

“WebSSO”=dword:00000000

Logs information relating to WebSSO.DLL for Web Single Sign-on (WebSSO.DLL only exists in older versions of SecureLogin).

“WinSSO”=dword:00000000

Logs information relating to Single Sign-on to Windows applications.

“Wizard”=dword:00000000

Logs information relating to the Wizard.

“LotusSSO”=dword:00000000

Logs information relating to Lotus Notes, if using ProNotes.DLL (doesn’t affect Notes installation that use a script for Lotus Notes).

“Parser”=dword:00000000

Logs information relating to the script parser.

“JavaSSO”=dword:00000000

Logs information relating to Single Sign-on to Java applications.

“JavaSSOBHO”=dword:00000000

Logs information relating to the Java Single Sign-on browser helper object (for SSO to web based Java applications).

“AWS”=dword:00000000

Logs information relating to advanced windows scripting features.

“IESSO”=dword:00000000

Logs information relating to Single Sign-on to Internet Explorer web based applications.

“XMLConv”=dword:00000000

Logs information relating to the XML converter that is able to export and import Directory data.

“TLaunch”=dword:00000000

Logs information relating to the terminal launcher application.

To enable debug log for SLNMAS create a registry key at HKLMSOFTWAREProtocomSecureLoginVirtual Channelslnmas and then create a string value called debug and set it to 1.

.

Related:

  • No Related Posts

7022886: Windows 10 v1709 Reports “Failed to Get Network Providers” under Advanced Settings of Network Connections

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

Environment

ZENworks Configuration Management

Situation

The “Provider Order” dialogue under Advanced Settings under Network Connections returns “Failed to get network providers”.
There are no other known issues associated with this issue at this time.

Resolution

Note: Only Create the ‘Devicename’ value specified below, if they keys under which it is to be created already exist.
Manually add a REG_SZ value named “DeviceName” under [HKEY_LOCAL_MACHINESystemCurrentControlSetServicesZenCredManagerNetworkProvider] and set the value to “DeviceZenCredManager”

Manually add a REG_SZ value named “DeviceName” under [HKEY_LOCAL_MACHINESystemCurrentControlSetServicesLCredMgrNetworkProvider] and set the value to “DeviceLCredMgr”

If the FDE Spoke is installed, the following may be necessary.

Note: Only Create the ‘Devicename’ value specified below, if they keys under which it is to be created already exist.
Manually add a REG_SZ value named “DeviceName” under [HKEY_LOCAL_MACHINESystemCurrentControlSetServicesPBACredManNetworkProvider] and set the value to “DevicePBACredMan”

Cause

The “DeviceName” value is defined as an Optional Attribute for Credential Providers.
Despite still being documented as optional by Microsoft in Windows 10 1709, when it is not defined it can impact the “Change Provider Order” starting in Windows 10 1709.

Status

Reported to Engineering

Additional Information

The OES Client may also cause the issue and requires a similar update to the registry.
Note: Other Credential Providers may cause the similar issue, so if the changes above do not resolve the issue….check for other 3rd party providers that may need similar entries created.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

  • No Related Posts

7021718: HLLAPI Shortname Configuration in INFOConnect and EXTRA!

HLLAPI Shortnames on Windows 8, Windows 7, Vista, and Windows Server 2008

In INFOConnect and EXTRA! (except EXTRA! on Windows 8 and later – see HLLAPI Shortnames in EXTRA! on Windows 8), the HLLAPI Shortname Associations can be either “Unique to each user” (the default) or “Shared among all users.”

Unique to each user

If you choose “Unique to each user.” the HLLAPI Shortnames can be accessed in the “Advanced” tab of the “Global Preferences” Options; however, the shortnames must be defined for each of the users that log on to that machine.

The “Unique to each user” settings are stored in the HKEY_CURRENT_USER hive of the Windows Registry.

Shared among all users

If you choose “Shared among all users,” the HLLAPI shortnames can be accessed in the “Advanced” tab of the “Global Preferences” Options, and the shortnames will be the same for all users that log on to the machine.

The “shared among all users” settings are stored in the HKEY_LOCAL_MACHINE hive.

HLLAPI Shortnames in EXTRA! on Windows 8 and Later

Shared HLLAPI session short name definitions are currently not supported when EXTRA! is installed on Windows 8. Session configuration data for a shared HLLAPI session is stored in a part of the registry that the user cannot change on Windows 8. Shared HLLAPI session shortnames can be entered using the Browse button, but the values are not retained and the next time you open the “Advanced” tab the HLLAPI Shortname Associations will be set to “Unique to each user” and no error messages or warning will appear.

Manual work-around to set the values for a “Shared among all users” configuration



1. Open Windows Regedit

2. For EXTRA! 9.4 navigate to HKEY_LOCAL_MACHINESoftwareWow6432NodeAttachmateEXTRA!WorkstationUser

For InfoConnect 9.4 navigate to HKEY_LOCAL_MACHINESoftwareWow6432NodeAttachmateAccessory ManagerWorkstationUser

3. Open the ConfiguredSessions key

4. Create a new String value (REG_SZ) key with a number (1,2,3, etc.) for the key name

5. Set the value of the string as follows: (the string is comma separated)

First element – fully qualified path and Host session file (*.EDP) for the HLLAPI shortname association

Second element – HLLAPI short name (letter a-to-z)

Third element – number of rows in Host session (includes OIA line)

Fourth element – number of columns in Host session

Fifth element – binary-encoded number that represents Host session “state” (typically 2443277)

Sixth element – typically zero

Seventh element – typically zero

EXTRA! 9.4 example:

C:Users<username>DocumentsMicro FocusEXTRA!SessionsSession1.EDP,A,25,80,2443277,0,0

InfoConnect 9.4 example:

C:Users<username>DocumentsMicro FocusInfoConnectSessionsSession2.EDP,B,25,80,2443277,0,0

The best way to determine the correct comma delimited string to use, is to run EXTRA! 9.x on a Windows 7 machine and take a look at the registry key for the appropriate values. InfoConnect 9.1 and later versions, under Windows 7, will not allow the user to set the HLLAPI value for “Shared among all users” under Global Preferences from the User Interface.

Once the appropriate registry key values have been determined, then this information can be manually deployed via a Windows *.REG file.

Related:

  • No Related Posts