Thursday, May 30, 2019

App-V Passthough Registry Keys


The registry keys which the Virtualised application can passthough to the physical registry are listed in this key

HKLM\SOFTWARE\Microsoft\AppV\Subsystem\VirtualRegistry\RemoteThroughPaths

Thursday, April 25, 2019

Useful network troubleshooting reference


Useful network troubleshooting reference

https://support.microsoft.com/en-us/help/325487/advanced-network-adapter-troubleshooting-for-windows-workstations

and it's gone. "Sorry page not found.  404."  Microsoft WHY do you do this? I'll just have to start copying out this stuff and posting it whole instead of using links.

Fortunately some one scraped it so its here

Monday, February 11, 2019

SC


This lists all SERVICE_NAME and DISPLAY_NAME items which match the string.

sc queryex type= service | find /i "string"

The DISPLAYNAME and SERVICE_NAME may be completely different strings though.

This command gets the SERVICE_NAME from the DISPLAY_NAME
sc getkeyname "SMS Agent Host"
returns
[SC] GetServiceKeyName SUCCESS
Name = CcmExec

This shows the windows service status.
sc query "SERVICE_NAME"

These are start/stop commands
sc start "SERVICE_NAME"
sc stop "SERVICE_NAME"

Friday, January 11, 2019

App-V Client Service Error 575















Windows could not start the Microsoft App-V Client on <machinename>.  For more information review the System Event Log.  If this is a non-Microsoft service, contact the service vendor, and refer to service-specfic error code 575.

This occured in some seemingly normal deployment collection change in SCCM.  Machines were moved from one collection where the package had already been targeted due to an upgrade, to another collection intended to be used for the specific version deployment.  The expected behaviour was that the SCCM client would detect the package was already applied and report "Already compliant" for the deployment stats.  That didn't happen........

The App-V clients were affected - in a bad way.

The app involved had the C:\ProgramData\Microsoft\AppV\Client\Catalog\Packages\{PackageGUID}  folder deleted then the service started fine.

Ran the Application Deployment Evaluation Cycle on the client and the SCCM client resurrected the package from the SCCM cache within a minute.

Root Cause - unknown.  Suspected corruption of the XML files in the catalog folder

Thanks to
http://blog.notmyfault.ch/?p=207

It was possible to do a mass correction / repair operation by deploying a powershell script to automate the above repair actions.

Tuesday, January 8, 2019

ATI 2018 recovery failure workaround

While attempting to recover a partition from a disk image backup, the recovery failed during several attempts, each time at a different disk sector.  The recovery was being carried out by booting from the bootable recovery media previously generated from the Windows Acronis True Image (ATI) Software onto a USB key.  The target drive was a Samsang EVO 840 500Gb SSD where the backup had been made from previously.

The error text is:

Acronis True Image
Failed to write data to the disk <sector number> of hard disk <number>
Failed to write to the snapshot manager drive. (0x1000DA)
Unknown status. (0x9)
The request could not be performed because of an I/O device error (0xFFF0)
Retry / Ignore / Ignore All / Cancel





















Some of the recovery job did proceed until the failure, each time at a different disk sector.  The suspicion was that the drivers for the SSD drive being written to were crashing out causing the failure.

To work around the problem, the latest bootable recovery media was downloaded from the Account area on the Arconis website.  A further problem then occurred.  The downloaded bootable recovery media was linux based and could not read the external USB 3.0 drive containing the disk images.  As the computer was still bootable from another drive and OS, the disk image was copied to an internal drive which the linux bootable recovery software could see.

The recovery then completed as expected without issue.

keywords recovery restore ATI Acronis True Image 2018

Friday, December 14, 2018