The Collection

A collection of useful information.

Filtering by Tag: registry

DSC: Registry Resource Binary Comparison Bug

Ever used DSC to set a binary registry value only to find out no matter how many times it sets it, it always thinks the value is incorrect?

The problem lies in MSFT_RegistryResource.psm1, @Ln926

$Data | % {$retString += [String]::Format("{0:x}", $_)}

Should be:

$Data | % {$retString += [String]::Format("{0:x2}", $_)}

Because it isn't, the value data, in this case:

ValueData = @("8232c580d332674f9cab5df8c206fcd8")

Which is 82 32 c5 80 d3 32 67 4f 9c ab 5d f8 c2 06 fc d8 in HEX dies because that 06 towards the end gets turned into a 6, even if that were valid hex it wouldn't match the input and thus the Test-DSCResource fails every single time.

App-V: Windows 7 locations.

Client Log File Location:
C:\ProgramData\Microsoft\Application Virtualization Client\sftlog.txt

Icon Cache:
C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\Icon Cache

OSD Cache:
C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\OSD Cache

Machine AppFS Storage:
C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\AppFS Storage

User AppFS Non-Roaming:
C:\Users\fulbripd\AppData\Local\SoftGrid Client

User AppFS Roaming:
C:\Users\fulbripd\AppData\Roaming\SoftGrid Client


Why would I need or want to know these locations?

Well, the OSD cache is important if you want to, say, suite something in-place (i.e. suite two applications together just on the machine to test integration or to hotfix someone until you can update it on the backend), the icon cache is useful for determining whether or not Windows Icon database is corrupt or if the icons provided by App-V are corrupt. The log file location is...hopefully obvious.

My personal favorite however is the AppFS locations.

I wouldn't worry to much about WHAT files are in there. But these locations are where the user changes that are saved "to the bubble" are stored. They are broken down into basically three types. Changes that are global (say, an HKLM key), changes that only apply to the user but shouldn't roam (say, an HKCU key with the machine name in it), and changes that are user specific and are ok to roam (say, an .ini file with preferences stored in it).

Where knowing this comes in handy is when, for whatever reason, the client decides to not truly clear the AppFS when you tell it to. I've had more than one instance of clearing multiple times, clearing after log off, after reboot, and the client just isn't capable of deleting it, maybe something random locked the folder, maybe something got corrupted, either way the only solution at that point is to find the folder for the app you want to clear and manually delete it in all three locations.

Likewise if you ONLY want to clear a certain segment of the AppFS for a package you can do so manually as opposed to the client which does not give you any options.

And example of what the folders look like it: CTXAPPS-3E12E23B-2C95-4986

You will notice after looking at a few that they tend to have the 8.3 folder name you used when you sequenced them, followed by a semi-GUID (semi because the first block is user generated and not random, therefor not TRULY globally unique).