This blog will be, again about some nasty Store Apps issues!. In the conclusion of my last blog, I was already mentioning the fact that I was looking into some Startmenu and the OneDrive/ Outlook connection issues that were occurring.
I will divide this blog into multiple parts
- The Issue
- Fixing it the old way
- Troubleshooting the Issue
- Fixing it the new way
- If you don’t want to fix it manually
- The Root Cause
- The possible first “Trigger”?
- Microsoft Outlook API
1. The issue
I guess I don’t need to mention that nasty 2022-05 update again, that broke the installations from the MS Store but when looking at the first time I noticed this Store issue (15-02-2022) this issue has been around for longer than the 2022-05 May update.
Let me explain what stops working.
- Outlook can’t connect anymore
- OneDrive stops syncing as it can’t connect anymore (0x8004de44) / Hangs on Signing in
- The Start menu is not responding on left click (right-click still works)
To give you a good idea of what is breaking, I also record it to let you show exactly what was happening!
Looking at all the stuff that is breaking, I guess we could just break the device and be done with it… but I guess we need to fix it, otherwise we wouldn’t be doing our job!
Now we know and have seen what stops working and if we didn’t break our device, we need to take a look at which events we would get if all that stuff breaks! Open your Application event log and start looking at all those excellent yellow warnings!
Event ID: 20
Triggered repair because operation LocalSettings against package Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy with error -2147024891.
Event ID: 21
Repair for operation LocalSettings against package Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy with error -2147024891 returned Error Code: –2147024891.
Event ID: 23
Triggered repair of state locations because of operation SettingsInitialize against package Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy with error –2147024891.
Event ID: 24
Repair of state locations for operation SettingsInitialize against package Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy with error -2147024891 returned Error Code: 0
It’s pretty obvious we are dealing with 2147024891 | 8007005 | Access Denied errors. But I am not done yet because another error caught my eye! As shown below, it is mentioning the 0xc000027b error.
The Application event log is not the only event log we need to dig into so let’s also take a look at the System event log. This event log is showing us the Kernel-General event 16 mentioning the application history in component AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Settings\settings.dat is deleted
Damn… Almost forgot one event log! As told earlier, when you are having sign-in issues with Onedrive and Outlook it’s always best practice to check out the AAD event log. As shown below even the AAD sign-in log is giving us the same 0x80070005 Access is denied error
2. Fixing it the Old way
When this weird issue started occurring we didn’t know exactly what was going on. At first, we just deleted the corrupted profile to make sure a new nice and shiny profile would be created
To do so we rebooted the device and logged in with a local admin user. After logging in we started deleting the c:\users\%username% folder and removing the user its profile key in the registry
With the old corrupted profile gone we could start logging in with the user again so the profile will be recreated. After logging in, please open your OneDrive and Outlook to make sure your Microsoft account is connected and working again!
Please Note: With the June update released we also made sure that we installed the June 2022-06 update which has the Store fix included.
3. Troubleshooting the issue
If we don’t want to recreate the profile and go through all the hassle to resync OneDrive etc we also have another option to fix it. As always I also looked if there was something useful in the MS-Docs.
Microsoft Store Apps fail to start – Windows Client | Microsoft Docs
When looking at the above link they do mention something about how to solve possible Store Apps issues.
That’s definitely one error (0xc000027b) we noticed before, right? I guess we have some missing permissions for “ALL APPLICATION PACKAGES” | AKA S-1-15-2-1 on some registry keys…. But which ones? because we have a lot of them!
When you are wondering what is happening in the registry, there is always Procmon!. Open Procmon and configure the filter first as shown below
Looking back at the error we got earlier 2147024891 –> Access denied. I will only add the filter “Include” the value “ACCESS DENIED”
As shown above, it is mentioning “Access Denied” on the HKU\S-1-12-1-2370815533-1185198546-48193434-4181760345\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer and the User Shell Folders registry keys. I guess that are the registry keys we need!
4. Fixing it the New Way
First, make sure the device got the 2022-06 update installed! Because the May update could break it again.?
When we are 100% sure the device is up to date open the registry (If you have the permissions to do so, otherwise run Regedit as admin and search for the correct user in the HKEY_USERS key) and validate the permissions on the below registry entries.
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
As mentioned before those registry keys need to have the “All Application Packages user” configured in the permissions and it also needs to have the “Read” box checked.
If the “ALL APPLICATION PACKAGES” user doesn’t have read permissions, you need to add them manually!
Of course, you could also automate the fix by using PowerShell. When looking at the script below that needs to be executed as an admin, It will first search for the SID of the Azure Ad user. After it got the right SID it will create a new-psdrive to make sure we can connect to the HKEY_USERS key.
After the PSDrive has been created it will add Readkey permissions for the missing “ALL APPLICATION PACKAGES” to the registry key
Please change the $packages to your own language
$Packages = "All APPLICATION PACKAGES"
$key = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-12-1-*'
$profiles = (Get-Item $key)
New-PSDrive -PSProvider Registry -Name HKU -Root HKEY_USERS
Foreach ($profile in $profiles) {
$sids = $profile
$sids = Split-path -path $sids -leaf
$user = "HKU:\$sids\"
$test = test-path $user
if ($test -eq $true){
$Folder = "HKU:\$sids\Software\Microsoft\windows\currentversion\explorer\"
$Acl = Get-ACL $folder
$AccessRule= New-Object System.Security.AccessControl.RegistryAccessRule($Packages,"Readkey","ContainerInherit","None","Allow")
$Acl.SetAccessRule($AccessRule)
Set-Acl $folder $Acl
$Folder = "HKU:\$sids\Software\Microsoft\windows\currentversion\explorer\user shell folders"
$Acl = Get-ACL $folder
$AccessRule= New-Object System.Security.AccessControl.RegistryAccessRule($Packages,"Readkey","ContainerInherit","None","Allow")
$Acl.SetAccessRule($AccessRule)
Set-Acl $folder $Acl
}
}
Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
After we made sure the permissions are all good, first let’s take a look if we maybe have some luck because changing the registry permissions resolved it for 75% of the devices.
If the problem still exists make sure you log in to the device with the USER who is experiencing this issue (NOT ADMIN, the user session! )
Once logged in, open 1 Elevated PowerShell session and 1 not elevated in the user it session. First, kill the explorer.exe with the use of the task manager.
Please note: When you don’t close the Explorer you could end up with some errors mentioning the resource is currently in use!
To fix that issue, I also added the -ForceApplicationShutdown to make sure the resources that are currently in use will be forced to shutdown
In the ELEVATED (RUN AS ADMIN) PowerShell session:
Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"} 
Please wait until it’s done! and just ignore the errors if you have any
In the NORMAL PowerShell session (in the user session)
Get-AppXPackage *Microsoft.Windows.Search* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode-ForceApplicationShutdown -Register "$($_.InstallLocation)\AppXManifest.xml"
}
Get-AppXPackage *MicrosoftWindows.Client.CBS* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register "$($_.InstallLocation)\AppXManifest.xml"
}
Get-AppXPackage *Microsoft.Windows.ShellExperienceHost* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register "$($_.InstallLocation)\AppXManifest.xml"
}
Get-AppXPackage *Microsoft.AAD.BrokerPlugin* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register "$($_.InstallLocation)\AppXManifest.xml"
}
Get-AppXPackage *Microsoft.AccountsControl* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register "$($_.InstallLocation)\AppXManifest.xml"
}
Get-AppXPackage *Microsoft.Windows.CloudExperienceHost* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register "$($_.InstallLocation)\AppXManifest.xml"
}
After this PowerShell script is run, please reboot the device or just start explorer.exe with the use of Taskmanager and you will notice everything is working again!
5. When you don’t want to fix it manually
I guess sometimes we are all lazy admins! When you don’t want to go through all of the hassles of fixing it manually you could always perform a “Fresh Start”
But beware it will take some more time before the user could use his device again because it needs to go through the whole Device and User ESP again to install the required apps. It’s up to you to choose the solution you are happy with
6. The Root Cause
After comparing all the devices with some people, we noticed that 1 specific App was installed on those devices.
It looks like somehow the ClickShare app broke at some point in time and at that moment it was responsible for messing up the ALL APPLICATION PACKAGES permissions on those registry keys.
Luckily Barco (ClickShare) is also confirming this issue and are fixing it with the latest update! So make sure when you deployed the Permissions fix you also make sure the ClickShare app is up to date!.
Shall I let you on to a little secret? Microsoft has its own PowerShell Script to fix it! Comparing this script with my own version, this script needs to be executed in the User session! where my script needs to be executed in the system context.
It pretty much does the same thing 🙂 … it does fixes the missing permissions.
$acl1 = Get-Acl "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\"
#$person = [System.Security.Principal.NTAccount]"all application packages" ##S-1-15-2-1
$sid = New-Object System.Security.Principal.SecurityIdentifier ("S-1-15-2-1")
$person_temp = $sid.Translate( [System.Security.Principal.NTAccount])
$person = $person_temp.Value.Split("\")[1]
$access = [System.Security.AccessControl.RegistryRights]"ReadKey"
$inheritance = [System.Security.AccessControl.InheritanceFlags]"ContainerInherit,ObjectInherit"
$propagation = [System.Security.AccessControl.PropagationFlags]"None"
$type = [System.Security.AccessControl.AccessControlType]"Allow"
$rule = New-Object System.Security.AccessControl.RegistryAccessRule($person,$access,$inheritance,$propagation,$type)
$acl1.AddAccessRule($rule)
$acl1 | Set-Acl
if (-not (Get-AppxPackage Microsoft.AAD.BrokerPlugin)) { Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown } Get-AppxPackage Microsoft.AAD.BrokerPlugin7. The possible first “Trigger”?
The ClickShare app is one of the apps that could mess up our Startmenu and broke the connection of our Office365 Apps but what could have triggered it? I already had some ideas about what could have triggered it but after noticing this post on Reddit, I became pretty sure
Intune: Mobile Device Management (reddit.com)
Looking at the Reddit post, the trigger could definitely be a self-service password reset by the user itself! After asking around some more, a lot of responses were the same:
“The user performed a password reset a couple of days before starting experiencing the issue”
8. Microsoft Outlook API
After some more digging, we found out that with the use of a Defender KQL query that Barco/ClickShare its calendarreader32.exe was setting the shell folder values. So it looked like the possible second trigger could be the Calendar/Outlook API.
In the meantime, while digging around some more I also got contacted by Barco. They wanted to share their research
Barco also added this issue to their own Knowledge base and with their own solution (Which pretty much does the same thing as I showed you earlier)
Knowledge Base – Unresponsive Windows taskbar with ClickShare App – Barco
In the email I got and in the Knowledge Base Barco is telling us it’s not a ClickShare App issue but it’s due to the fact that the ClickShare app uses the Microsoft Outlook API...
Combining their results with the stuff we have noticed… I guess all other Apps that just use the Outlook API could break the StartMenu. I guess the next question will be… when did the Microsoft Outlook API start to give us the issues.
Conclusion
All those Store Apps issues we are experiencing the last few months are awful. Luckily most of the issues can be resolved. This blog will explain how you could solve issues with the start menu, Onedrive, and Outlook.
Please Note: I am still looking for the “why”! If I have more information I will share it with all of you!
If you are interested in solving issues with the Offline Company portal app please check out this blog
Company Portal not working after performing a Wipe/Reset (call4cloud.nl)
Thanks for this, it was a life saver.
I did however run into a couple problems.
1. If there are multiple profiles on the device the $DelFind = (Get-Item $key) returns multiple items and $sid contains more than 1 SID, so how do you get the correct SID?
I bypassed this by just setting $sid = ‘paste the current user SID from Registry’
2. Even after completing both ‘Fixes’ and rebooting the Search window was not working. This was only on some PC’s. I have not figured out how to fix that yet.
Hi.. it s on my list to take a look at it to make sure that for each it will be fixed
I updated the script so it works a little bit better when there are multiple sids
Finally a solution!
For the registry permissions, I noticed the all app account was missing from HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
The inheritance was also broken (I compared it to a working laptop), so I removed the accounts already there and enabled the inheritance and applied to all child objects. A few other apps were still not working, like the search bar, but the AppXPackage PS took care of that.
“It will first search for the SID of the Azure Ad user.”
Will this also work for on-prem or hybrid setups?
Is anyone who’s experiencing this issue happen to have ClickShare MSI installed on their machines?
That’s indeed one in my list of possible issues… but indeed I am noticing that app being installed on those devices
We have ClickShare installed in our environment and are experiencing this issue.
The updated blog will show you it is probably caused by clickshare indeed
We have had this issue on hundreds of workstations so far, all of them with ClickShare. We scripted a way to delete the affected profile and reinstate all the necessities with minumum fuss, but could not figure out why it broke. Thanks for this!
We are now upgrading a few thousand workstations to ClickShare 4.22.0.13, and crossing our fingers.
Nicklas, any way you could share that script?
We don’t have ClickShare, but do have this problem.
Has the windows search been fixed? The script from microsoft fixes Outlook/Teams/One drive/start menu, but search function from the taskbar is not working.
Going to look at it when i have a broken device to test with 🙂
Same thing here Office apps are working after the fix. But startmenue / searchbar don’t.
Usual taskbar fixes also don’t help – any suggestions?
Did you tried ms their fix or the first fix I was mentioning ? as that fix, fixed the apps and the start many for a lot of devices
I guess I need some logs to check out what is happening because I don’t have a device experiencing those issues anymore.. So feel free to send me the logs (application and appmodel-runtime) so I could check it out
Hi Rudy,
Thanks for this article, could it possible that may update also broke addins. In my case mimecast for outlook stopped working. Manuall upgrade/install would fail with error 1603.
I had to repaire O365 apps online to get it working.
The may update did indeed also break some stuff… not all but some of them did indeed break
Thanks! Real help!
Message from the ClickShare team:
As quality and security are always top of mind for ClickShare, we are aware of the reports on an unresponsive Windows taskbar for end-users. Our team has been working hard to analyze these. Up-to-now there is no evidence that the issue is related to the ClickShare App. Of course, we keep on investigating and monitoring.
To help users of the ClickShare App get back to work asap, we recommend to uninstall the ClickShare App, run the Microsoft updates, reboot the laptop and re-install the latest update of the ClickShare App.
Hi.. just received confirmation… last friday we also noticed the ksql query that the clickshare app (calandarreader32.exe) is fighting for those permissions (Microsoft API).. I guess barco now shares the same conclusion…
I can confirm we have the exact same behaviour but do not use clIckshare at all but do have a few other applications likely accessing the same API mentioned by Barco
Hi… I guess apps like zoom could also access that API indeed… wondering which apps you are noticing on this problem devices
We have not been able to narrow that down, does ClickShare add an add-in to Outlook or is it just an app using MAPI to read a users Outlook calendar? I am also curious does this issue only happen on devices with multiple Outlook Profiles or multiple mailboxes or calendars from what you are seeing?
We’ve found this restores most of the functionality of the devices but there are a couple of things.
Single Sign On is still broken, all the apps will ask you to sign in once the repair has been tried, and in the taskbar the volume, battery and network control functions still don’t work.
The other thing we’ve noticed is that while it is true that the reason for the start and search menu issue is because.
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
Are missing the read permissions for “All Application Packages User”, it is because those two locations have lost inheritance which is why it has lost those permissions.
Hi.Looking at as example to the solution of barco… they will enable inheritance again.. So I assume the inheritance was lost in the first place.
If you have applied the fix, did you reboot the device? Because of the aadbroker plugin also got corrupted, it will break the sso at that point in time.
Yes we’ve managed to repair SSO now, they only function that is still broken, are the network, volume and battery functions in the taskbar, I assume there is another reg key for those that needs to have its inheritance enabled again.
Mmm thats weird.. as I didnt experienced that behavior myself. Did you also made sure to run the user powershell script to make sure the packages are reinstalled properly ?
Yes, tried running this across multiple devices now and those functions are still not available, the Date/Time is also not working, while they will update, such as the Battery icon sill tracking the charge level, but you can’t left click on any of them to access their features.
I believe I’ve found the problem, the command for installing the Shell Experience Host isn’t working on our devices for some reason, as I’ve checked with
Get-AppXPackage -AllUsers |Where-Object {$_.InstallLocation -like “*SystemApps*”} and it isn’t installed for the impacted user.
The command to install it,
Get-AppXPackage *Microsoft.Windows.ShellExperienceHost* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register “$($_.InstallLocation)\AppXManifest.xml”
}
Runs but doesn’t install anything.
Brilliant! your PS script helped. The only possibility that has helped me in the last few weeks and months was a long-lasting Windows inplace update. According to your script, the start button works and after a reboot also the search field. Thanks a lot. Small note: we do not use clickshare. We had a problem with HTML mails in combination with Kerio Connector with the last Outlook365 v2205. (This has since been fixed by Kerio/GFI). That only as a tip in the direction of the MAPI interface.
Thanx! at first we thought it was because of the clickshare app.. as 99% of all device with the issue had that app installed 😛 … but as I was also showing it was more about the outlook API which was called upon by the app 🙂
Great Blog!
Unfortunately the search bar is still not working after applying your fixed so I had to recreate the users profile.
Hi..To be sure, you first made sure you executed the first part as an admin… and afterwards you registered all those apps in the user session?
Get-AppXPackage *Microsoft.Windows.Search* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode-ForceApplicationShutdown -Register “$($_.InstallLocation)\AppXManifest.xml”
}
And if its done reboot the device
I am wondering for those with the issues, what update channel you are on for M365 Apps?
In trying to narrow this down, I believe it is an Outlook update and specifically looking through release notes and trying to build a timeline, it seems to correspond with this “Fix” in release notes:
“We fixed an issue that prevented Outlook Event-Based Add-Ins from functioning properly.”
Current Channel started getting this Fix in April (Specifically on the 20th)
Monthly Channel started getting this fix in May (Specifically on the 10th)
Semi-Annual started getting this fix this month in June (Specifically on the 14th)
We are starting to roll back to a version prior to the Semi-Annual release to test as we do not run ClickShare or Kerio Connect which is another app triggering the same issue but have several different apps hitting Outlook and the issue is so sporadic we have not been able to pinpoint it exactly yet but leaning towards Mimecast at the moment.
Hi.. True, this information was also shared with Barco when we were looking into it, as there could be indeed a possibility its because of this update/change in the ms apps.. But because its almost holiday everywhere :).. SO I am not sure until Microsoft tells us something…. when I know for sure I will get back to you
Great Article! And thank you so much for having published it! We have the same issue and already open Microsoft tickets without any solutions.
Here is my quick fix (run with user privilege) to resolve it:
Rename-Item -Path “HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders” -NewName “User Shell Folders_old”
Rename-Item -Path “HKCU:\SOFTWARE\Microsoft\Office\16.0\Common\Identity”-NewName “Identity_old”
if (-not (Get-AppxPackage Microsoft.AAD.BrokerPlugin)) { Add-AppxPackage -Register “$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml” -DisableDevelopmentMode -ForceApplicationShutdown } Get-AppxPackage Microsoft.AAD.BrokerPlugin
logoff
We are still investigating where this issue is coming from!
Hi… it looks like the issue is caused by the Microsoft outlook API which other third part tools like zoom, barco are using
Hi, yes and we have the proof that for our case is coming from:
C:\ClickShareApp\ClickShare\app-4.22.0-b13\calendarreader64.exe
We found that by turning on permissions auditing on the registry key:
“HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders” to monitor what permission are modified and boom we got the executable that is causing the issue.
Here is the event log collected :
———————————-
Permissions on an object were changed.
Subject:
Security ID: ITEOS\username
Account Name: username
Account Domain: ITEOS
Logon ID: 0x194C60ED
Object:
Object Server: Security
Object Type: Key
Object Name: \REGISTRY\USER\S-1-5-21-130038992-1272150033-662139138-xxxxx\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
Handle ID: 0x15f4
Process:
Process ID: 0x1ea0
Process Name: C:\ClickShareApp\ClickShare\app-4.22.0-b13\calendarreader64.exe
1. First Change
Original Security Descriptor:
D:P(A;OICI;KA;;;S-1-5-21-130038992-1272150033-662139138-xxxxx)(A;OICI;KA;;;SY)(A;OICI;KA;;;BA)(A;OICI;KR;;;RC)(A;OICI;KR;;;AC)(A;OICI;KR;;;S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681)
NT AUTHORITY\RESTRICTED: AccessAllowed (ExecuteKey, ListDirectory, ReadExtendedAttributes, ReadPermissions, WriteExtendedAttributes),
NT AUTHORITY\SYSTEM: AccessAllowed (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey),
BUILTIN\Administrators: AccessAllowed (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey),
ITEOS\username: AccessAllowed (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey)…}
New Security Descriptor:
D:AI(A;ID;KR;;;BU)(A;CIIOID;GR;;;BU)(A;ID;KA;;;BA)(A;CIIOID;GA;;;BA)(A;ID;KA;;;SY)(A;CIIOID;GA;;;SY)(A;CIIOID;GA;;;CO)(A;ID;KR;;;AC)(A;CIIOID;GR;;;AC)(A;ID;KR;;;S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681)(A;CIIOID;GR;;;S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681)
BUILTIN\Users: AccessAllowed Inherited (ExecuteKey, ListDirectory, ReadExtendedAttributes, ReadPermissions, WriteExtendedAttributes),
BUILTIN\Administrators: AccessAllowed Inherited (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey),
NT AUTHORITY\SYSTEM: AccessAllowed Inherited (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey),
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES: AccessAllowed Inherited (ExecuteKey, ListDirectory, ReadExtendedAttributes, ReadPermissions, WriteExtendedAttributes)…}
2. Second change
Original Security Descriptor:
D:(A;ID;KR;;;BU)(A;CIIOID;GR;;;BU)(A;ID;KA;;;BA)(A;CIIOID;GA;;;BA)(A;ID;KA;;;SY)(A;CIIOID;GA;;;SY)(A;CIIOID;GA;;;CO)(A;ID;KR;;;AC)(A;CIIOID;GR;;;AC)(A;ID;KR;;;S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681)(A;CIIOID;GR;;;S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681)
Same as above…
New Security Descriptor:
D:PAI(A;OICI;KA;;;S-1-5-21-130038992-1272150033-662139138-xxxxx)(A;OICI;KA;;;SY)(A;OICI;KA;;;BA)(A;OICI;KR;;;RC)
NT AUTHORITY\RESTRICTED: AccessAllowed (ExecuteKey, ListDirectory, ReadExtendedAttributes, ReadPermissions, WriteExtendedAttributes), NT AUTHORITY\SYSTEM: AccessAllowed (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey),
BUILTIN\Administrators: AccessAllowed (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey),
ITEOS\username: AccessAllowed (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey)}
————————————–
After decoding those changes with PowerShell and the command line ConvertFrom-SddlString, we can clearly see that :
In the Second change the process calendarreader64.exe remove the permissions for NT AUTHORITY\SYSTEM & ALL APPLICATION PACKAGES
Can you help us to have contact with Barco to resolved ASAP this issue ?
Thank you