Sanchez

Hi. I'm testing the roll out of Windows 10 22H2, and have encountered some odd problems. Most computers in the company are currently on Windows 10 20H2, and we have no problems with them. I've updated a handful to 22H2 - some with an enablement package, and others have been re-imaged with a task sequence. All 22H2 machines are facing the same problems. First of all, driver installation always fails during the task sequence. The only difference between the 20H2 and 22H2 task sequences is the choice of OS image and Unattend.xml. This is a status message from one of the driver installation steps: The other problem is that no updates are showing up in Software Center (on 22H2). All the applications are there, though. I've looked through a bunch of logs, and can't see anything obvious, so am not sure of the next step. Any suggestions? Thanks.

Weirdly, I've just found that it doesn't happen on one of my test VMs - one which has no other software installed. On the other two (which have plenty of programs installed), and on user workstations, it happens. 🤷‍♀️

Perfect; thanks! Install an old version of 7-Zip (as an example), on a test workstation. Launch 7-Zip File Manager Create an application in SCCM, with the newest MSI version of 7-Zip (standard MSIExec switches). In the Install Behavior tab of the deployment type, add 7zFM.exe as an executable that must be closed. Deploy the application as required, to the test workstation, and make sure to leave "Automatically close any running executables you specified..." un-checked. Run the machine policy and application deployment evaluation cycles, to hurry things along. The first time you do this, the content will be downloaded, and the installation will fail (as it should). Do the same again, and this time, the installation will proceed, and 7-Zip File Manager will be terminated. At least that's what's happening here (just tried all of that myself). If you trigger it manually, by clicking "Install" in Software Center, it behaves as it should - the installation fails, and the application stays open. Is that enough detail, or do you need a step by step? Thanks.

Thanks. I thought it might be a bug, but Googled it and wondered why nobody else seemed to have mentioned it. So far, I've just sent feedback, but yeah, I should probably raise a case. I wonder if anyone else is able to verify this behaviour in their environment, to make sure it's not just mine. Thanks.

Hi. It seems that Install Behavior isn't working properly in the latest versions of Configuration Manager, as it is automatically closing applications, when it's not supposed to. I'm deploying an application, and have specified an executable that must be closed for the application installation to succeed, in the "Install Behavior" tab of the deployment type. I've created a required deployment for the application, but the "Automatically close any running executables..." option is un-checked. Despite that, when the deployment deadline is reached, the executable gets terminated. I would expect the installation to fail, without terminating the executable, which is what I want (and what it always used to do). I've tried this with a couple of different application deployments, and they both do the same thing. I had employed that method successfully a number of times in the past, to depoy applications as required, without having to worry about interrupting peoples' work. I first noticed the problem a couple of weeks ago, with Configuration Manager version 2103. I upgraded to version 2107, hoping that would resolve the issue, but it hasn't. The "Show notifications for new deployments" option in client settings is set to "No", as I don't want users being nagged when I deploy new applications, but that's never been a problem before. Is anyone else seeing this behaviour? Thanks.

Thanks, radish. I am pretty sure that both methods (automatically-triggered and via Software Center) use the system account, but if anybody knows different, I'd like to hear it. Understanding the exact difference between the two will help troubleshoot and explain it to the developer. Thanks.

Thank you. Personally, I can't see anything of note in those logs. The only relevant clue is in Windows application logs, which record the installer's executable crashing: Exception code 0xc0000005 is a memory violation, and the exit code in AppEnforce (3221225477) seems to mean the same thing. I'll speak to the developers, but it's just strange how this only happens when triggered automatically. All these logs are from a VM with Windows 10 1909, and no software installed. The only antivirus is Windows Defender, which I disabled by local Group Policy. AppLogs.zip

Hi. What does your Format and Partition Disk task sequence step look like?

Thanks for your reply. There's nothing documented, to say that the application requires a user to be logged-on, but I thought SCCM always used the system account, anyway. In both scenarios, the installer's temporary files and logs appear in C:\Windows\Temp, as opposed to the user's %Temp% folder, which is the bahaviour of the system account. Either way, I always test my deployments using PSExec to run the installer in the system context, and that always works, with this application. Also, the installation fails whether a user is logged-on or not, I'm afraid. So I don't know where that leaves us. Thanks.

Hi. I have an application which has a "required" deployment. If I leave it to install by itself, it always fails. But if I log-on to one of the target computers, open Software Center, go into the deployment and click "Install", it always works. So what I'm wondering is: when SCCM automatically triggers the deployment, how is that different to triggering it from Software Center? Why would one work, but not the other? I suspect the problem is to do with the executable itslelf, but understanding the mechanics of how the two scenarios differ, could help me test and troubleshoot the issue. I hope someone can shed some light! Thanks.

Thanks for your help. Microsoft looked as well, and couldn't figure it out, but they disabled software inventory. I didn't get time to look at it for about 6 months, but when I re-enabled it, everything was working again. I guess some corrupted data got stuck in there somewhere, and leaving it disabled for 6 months flushed it out.

As for SW inventory: Anything else I'd need to configure, to get it inventorying correctly?

Yes, thanks Garth; I've read all that, and am taking it into account. As mentioned, I also followed your guide here: https://www.enhansoft.com/updated-how-to-create-a-sql-server-computer-account-login/, and it was already configured like that: I ran the test as you described, and it was successful (the below test was performed on the site server): As far as I understand, it's not the site server's account that's having a problem. NT AUTHORITY\SYSTEM is the local system account on the (separate) SQL server, isn't it? If it were the site server, the errors would show as <computer name>$, wouldn't they?

Well, I wanted to double-check my previous experiment, so again, I mapped "NT AUTHORITY\SYSTEM" to the SCCM database, and gave it db_owner role membership. The permissions on the reports now look fine, and users can access them as expected. But I don't see this as a solution, as doing this isn't mentioned in any documentation or guides, so there must be an underlying problem. And I've also read that it's not a good idea, from a security standpoint. As for SW inv, I've traced it through all the logs I know of, and it seems to be going through the steps it's supposed to, without errors. But the reports are still empty, including the "All inventoried files..." ones. Thanks.

Thanks for that, Garth. I was aware of the issues around software inventory, but I think your posts have finally persuaded me to turn it off. However, before I do that, I want to figure out why these tables aren't being populated, and why the permissions seem screwy. I agree that inventorying .exe is rather excessive, but I was trying to mirror the settings on the old server (set up long before my time), which was working perfectly well. Oh and sorry for the misunderstanding; I didn't mean I'd configured it just now. I meant "simply". It's been like that since about October last year. Anyway I'm thinking more and more that this is a fault, and not that I've mis-configured something, so I'm going to try re-installing the reporting point, to see if that fixes it. After that, it's a call to Microsoft. Thanks for your help!