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

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

https://mskb.pkisolutions.com/kb/325487

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"

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.

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

Windows 10 data slurping

Windows 10 data slurping and how to limit it.

https://www.theregister.co.uk/2018/12/13/windows_10_carry_on_slurping/

Repairing SCCM Client WMI issues.

Occasionally clients will develop a problem with their WMI which impacts the operations of the SCCM client.  For example Application Deployment Evaluation Cycle will not respond or trigger the check / update.

The giveaway is a sea of red in the DcmWmiProvider.log with errors such as

Not found (Error: 80041002; Source: WMI)

At this point you can deduce that your WMI information is corrupted and needs to be rebuilt.

Another symptom is the inability of the SMS Agent Host (ccmexec) service to stop in a timely way.  It will try but then hang in a pending stop state.  This is annoying since this needs to be stopped before the Windows Management Instrumentation (Winmgmt) service can be stopped.

You may need to force the ccmexec service stop to proceed.

To do that,

sc queryex ccmexec

this output the process ID (PID) reference.  Force it down with

taskkill /f /PID <PidReference>

Personally I find it easier to manage the services in the services.msc applet.

Stop the Windows Management Instrumentation (Winmgmt) service.  This is not that easy to do because it will restart immediately.  It may need disabling for a short period while folder operation is done.

delete or rename the C:\Windows\System32\Wbem\Repository folder

Then restart the the Winmgmt service and the ccmexec service.

At this point you have caused chaos because, well, there's no WMI data at all ! :)

The SCCM Client will freak and run a repair operation to try and right itself while writing a log called repair-msi-<GUIDstring>.log It may get a 1603 error in which case it may retry until it gets a 0.  I've seen 1603 on the first attempt and 0 on the second.

After that the SCCM client tries to rebuild its world and get all its apps assignment polices - slowly.  On the machine this process occurred on it was about 3 hours with an end of day shutdown and a start of day boot up, and a forced restart on the ccmexec service.  Eventually normal service was resumed and the apps it was supposed to apply, did so.