MSI, App-V, SCCM, Appsense, Citrix. This blog contains hints and tips on these technologies. Primarily it is an online notebook of items that I may need to refer to in the future, or things I constantly forget!
Tuesday, June 11, 2019
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
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
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/
Subscribe to:
Posts (Atom)
