SCCM Task Sequence with App-V application "A supported App-V 5X client is not installed"
Scenario: Windows 10 (1607) Task Sequence with various MSI and App-V applications. During an SCCM Task Sequence I am attempting to install an App-V application however, at the end of the build MSI installations have installed but App-V application has not been installed.
AppDiscovery.log
Performing detection of app deployment type MathWorks_MATLAB-R2014a_8.3.0.532_001A - Download.....
+++ App-V 5X application not discovered. A supported App-V 5X client is not installed.
Resolution: With Windows 10, version 1607, the App-V client is installed automatically however, it needs to be enabled before you can installations App-V packaged within a Task Sequence. This can be achieved by adding a command line to you Task Sequence to run Windows PowerShell command.
powershell -executionpolicy bypass -command Enable-Appv
Thursday, June 29, 2017
Tuesday, June 20, 2017
Windows 10 Creates 4 New Folders
Scenario: On the root of the C drive you right click and select New "Folder". Windows will then create 4 New folder i.e. New Folder, New Folder (2), New Folder (3), New Folder (4). To delete or open these folders you need to elevate permissions on each one.
We have seen this issue only occur on Windows 10 systems applying Group Policy.
Cause: In our environment a specific Group policy was filtered to Windows 10 only. Within this policy the following security setting was set to modify C: drive file permissions:
Computer> Policies> Windows Settings>File System
The policy specifically was allowing Administrators Full Control and Users Read and Execute permissions to "This Folder" only. This had the affect of preventing sub-folders from inheriting Administrator / Users permissions.
If this policy does not exist or is set to "This folder, Sub-folders, and files" then the additional Folders are not created.
I believe this issue is a bug in the way Windows attempt to create the folder and inherit permissions; by default the folder will inherit from above but with this policy in place it fails to inherit and tries 4 times before timing out. Each attempt results in a restricted folder.
We have seen this issue only occur on Windows 10 systems applying Group Policy.
Cause: In our environment a specific Group policy was filtered to Windows 10 only. Within this policy the following security setting was set to modify C: drive file permissions:
Computer> Policies> Windows Settings>File System
The policy specifically was allowing Administrators Full Control and Users Read and Execute permissions to "This Folder" only. This had the affect of preventing sub-folders from inheriting Administrator / Users permissions.
If this policy does not exist or is set to "This folder, Sub-folders, and files" then the additional Folders are not created.
I believe this issue is a bug in the way Windows attempt to create the folder and inherit permissions; by default the folder will inherit from above but with this policy in place it fails to inherit and tries 4 times before timing out. Each attempt results in a restricted folder.
Friday, June 9, 2017
SCCM Unknown computer not able to see Task Sequences after installing Current Branch 1702
Soon after installing SCCM CB 1702 we were unable to see Task Sequences deployed to the unknown collection.
This issue was identified as a random system taking the GUID of the 'x64 Unknown Computer (x64 Unknown Computer)' record. As a result it was now a known GUID; as we were only deploying Task Sequences to the Unknown collection none were made available.
'x64 Unknown Computer (x64 Unknown Computer)' record
'x86 Unknown Computer (x86 Unknown Computer)' record
To get the GUID of your unknown systems open SQL management studio and run the following command:
--Sql Command to list the name and GUID for UnknownSystems record data
select ItemKey, Name0,SMS_Unique_Identifier0 from UnknownSystem_DISC
Using the returned GUID (SMS_Unique_Identifier0) we can find the hostname that has been assigned the 'x64 Unknown Computer (x64 Unknown Computer)' GUID by running the query below.
--x64 Unknown Computers
select Name0,SMS_Unique_Identifier0,Decommissioned0 from System_DISC where System_DISC.SMS_Unique_Identifier0 = '##Enter-GUID-Here##'
The query returned the hostname GUID and whether it is present within the SCCM database. A '1' implies the record is deleted and will be purged from the database. We saw a '0' imply the opposite.
Resolution
Deleting the 'x64 Unknown Computer (x64 Unknown Computer)' record and recreating the record through the steps below had limited success. The issue was resolved until the new GUID created for 'x64 Unknown Computer (x64 Unknown Computer)' was used again.
delete from UnknownSystem_DISC where ItemKey in (##ItemKey##)
HKLM\Software\Microsoft\SMS\Components\SMS_Discovery_Data_manager
Key:
CreatedUnknownDDR Change the entry to 0
Restart SMS Executive this then recreates the Default x86 and x64 unknown collections
Microsoft has since release a Update Rollup KB4019926 which other sources were hailing as the fix.
https://support.microsoft.com/en-us/help/4019926/update-rollup-for-system-center-configuration-manager-current-branch-v
After applying the Rollup we were still receiving reports of the Unknown GUID being assigned to systems. It was identified that when a build used the "Previous" button within WinPe (after a dependancy failure or simply to refresh task sequence policy) the task sequence would take the Unknown GUID still.
What was not highlighted in the documentation for the Rollup was the requirement to either recreate or update distribution points with the current Boot Image and then if you use USB boot media recreate this.
This issue was identified as a random system taking the GUID of the 'x64 Unknown Computer (x64 Unknown Computer)' record. As a result it was now a known GUID; as we were only deploying Task Sequences to the Unknown collection none were made available.
'x64 Unknown Computer (x64 Unknown Computer)' record
'x86 Unknown Computer (x86 Unknown Computer)' record
To get the GUID of your unknown systems open SQL management studio and run the following command:
--Sql Command to list the name and GUID for UnknownSystems record data
select ItemKey, Name0,SMS_Unique_Identifier0 from UnknownSystem_DISC
Using the returned GUID (SMS_Unique_Identifier0) we can find the hostname that has been assigned the 'x64 Unknown Computer (x64 Unknown Computer)' GUID by running the query below.
--x64 Unknown Computers
select Name0,SMS_Unique_Identifier0,Decommissioned0 from System_DISC where System_DISC.SMS_Unique_Identifier0 = '##Enter-GUID-Here##'
The query returned the hostname GUID and whether it is present within the SCCM database. A '1' implies the record is deleted and will be purged from the database. We saw a '0' imply the opposite.
Resolution
Deleting the 'x64 Unknown Computer (x64 Unknown Computer)' record and recreating the record through the steps below had limited success. The issue was resolved until the new GUID created for 'x64 Unknown Computer (x64 Unknown Computer)' was used again.
delete from UnknownSystem_DISC where ItemKey in (##ItemKey##)
HKLM\Software\Microsoft\SMS\Components\SMS_Discovery_Data_manager
Key:
CreatedUnknownDDR Change the entry to 0
Restart SMS Executive this then recreates the Default x86 and x64 unknown collections
Microsoft has since release a Update Rollup KB4019926 which other sources were hailing as the fix.
https://support.microsoft.com/en-us/help/4019926/update-rollup-for-system-center-configuration-manager-current-branch-v
After applying the Rollup we were still receiving reports of the Unknown GUID being assigned to systems. It was identified that when a build used the "Previous" button within WinPe (after a dependancy failure or simply to refresh task sequence policy) the task sequence would take the Unknown GUID still.
What was not highlighted in the documentation for the Rollup was the requirement to either recreate or update distribution points with the current Boot Image and then if you use USB boot media recreate this.
Subscribe to:
Posts (Atom)