CreateProcessAsUser Error 5 - ServiceUI.exe
Hi All I've recently updated my SCCM Site version to v1910, since performing this update i've been having issues with my Upgrade Task Sequence. Previously i've had a command line step in the upgrade task sequence to run a manually built "Windows 10 Splash Screen" using ServiceUI.exe to allow the user to install or postpone the upgrade. This has been issue free until the update to SCCM 1910, since then when i try to run the task sequence the following step fails with this error. Has anyone got any idea how i can resolve this? Been racking my brain for days now...
Local administrator created during OSD doesn't get administrator access
This is an issue at the intersection between application deployment (via task sequence) and operating-system deployment. I have a setup.exe installer (actually, several of them, all part of the same collection - but the issue can be illustrated by talking about just one) which works fine when run as an ordinary local administrator, but fails with error 1619 when run as SYSTEM. As best I've been able to determine, the installer detects that the embedded MSI would be extracted to a location under the Windows folder, decides that's a security violation, and intentionally does things in a way that will result in this error. To work around this, I have created a task sequence (without a boot image) to run the installation as a temporary local administrator account. Specifically, this task sequence has the following series of actions: * A Run Command Line action to create a new local user account, by running 'net user TEMPORARYUSERNAME PASSWORD /add'. * A Run Command Line action to add that user to the local Administrators group, by running 'net localgroup Administrators TEMPORARYUSERNAME /add'. * A Run Command Line action to invoke the setup.exe from its package, with the "run this step from the following account" box checked, the username set to '%computername%\TEMPORARYUSERNAME', and the password entered accordingly. * A Run Command Line action to delete the temporary local user, by running 'net user TEMPORARYUSERNAME /delete'. If I create a deployment of this task sequence to a collection, and invoke it manually from the Software Center, it works; the program is installed as intended, and the user is created and cleaned up along the way. Event Viewer does log a warning (or perhaps an error) indicating having failed to load the user profile for this account, but that doesn't seem to do any harm, and I haven't yet found any way to avoid having it happen. If I then go to an OSD task sequence and add a Run Task Sequence action (after rebooting out of Windows PE and into Windows proper) which invokes the above task sequence, and then deploy that OSD task sequence to a computer, the embedded task sequence fails. More specifically, it gets as far as the action which invokes setup.exe, and then records that the installation failed with error 1603. As best I can determine based on analyzing the logs, the 1603 in this case is a simple "access denied" error, and means that the account which is being used to run the program does not have write access to the install location. However, because the user has been added to the local Administrators group, that user should have Administrator-level access to the entire system - including the install location. The fact that this install succeeds when invoked from Software Center seems to indicate that this user *does* in fact get such access in that environment - but in the post-WinPE OSD environment, it apparently does not. I have gone so far as to add a reboot step in between the step which adds the temporary account to the local Administrators group and the step which invokes setup.exe, in the hopes that the reboot would lead the system to recognize that the temporary account is a member of that group. However, this did not appear to produce any change in the behavior of the setup.exe step. My first question is: How can I get Windows to properly grant local Administrator access (and, as a consequence, write access to the install location) to this user no matter which environment the "inner" task sequence is run from? If there's no apparent way to do that, my second question is: How else can I get this install to run as a non-SYSTEM user with local administrator access? Running as the built-in administrator account itself is not really an option. We manage that account's password with LAPS, so while I know what that password is at Windows install time, as soon as we join the domain (which, for various reasons, will have happened by this point in the task sequence) there's a possibility that the password will have changed; as a result, I can't specify that password in the Run Command Line action.
Win7 to Win10 1803/1809 in-place upgrade Task Sequence breaks with no apparent error code
Hi, We’re migrating from Win7SP1 to Win10 Ent. 1803/1809 in our corporate environment. Strange thing noticed is migration TS always breaks on Latitude E7470 after ‘Upgrade Operating System’ task. Other models (E7440, E7450, E6440, O7010, O9020, T7910, etc.) don't have such issue at large. Almost 50 nos. of E7470 is tried and all of them got the same issue. Currently migration on this particular model is on hold. Didn’t see anyone mentioning the same issue anywhere. TS screenshot as well as last few lines from smsts.log is copied below. As you can see there is no error reported by the task. But a reboot is initiated somehow, which breaks Task Sequence and then it doesn’t go further. In general, what are the reasons why such error occur?! Process completed with exit code 0 TSManager 19/06/2019 18:55:23 7816 (0x1E88) !--------------------------------------------------------------------------------------------! TSManager 19/06/2019 18:55:23 7816 (0x1E88) Successfully completed the action (Upgrade Operating System) with the exit win32 code 0 TSManager 19/06/2019 18:55:23 7816 (0x1E88) Not in SSL TSManager 19/06/2019 18:55:24 7816 (0x1E88) Set a global environment variable _SMSTSLastActionRetCode=0 TSManager 19/06/2019 18:55:24 7816 (0x1E88) Set a global environment variable _SMSTSLastActionName=Upgrade Operating System TSManager 19/06/2019 18:55:24 7816 (0x1E88) Set a global environment variable _SMSTSLastActionSucceeded=true TSManager 19/06/2019 18:55:24 7816 (0x1E88) Clear local default environment TSManager 19/06/2019 18:55:24 7816 (0x1E88) The action (Upgrade Operating System) requested a retry TSManager 19/06/2019 18:55:24 7816 (0x1E88) Created volatile registry entry for pending reboot initiated by this task sequence TSManager 19/06/2019 18:55:24 7816 (0x1E88) Executing command line: "bcdedit.exe" with options (0, 0) TSManager 19/06/2019 18:55:24 7816 (0x1E88) Process completed with exit code 0 TSManager 19/06/2019 18:55:24 7816 (0x1E88) TSUEFIDrive: TSManager 19/06/2019 18:55:24 7816 (0x1E88) Updated security on object C:\_SMSTSVolumeID.7159644d-f741-45d5-ab29-0ad8aa4771ca. TSManager 19/06/2019 18:55:24 7816 (0x1E88) Updated security on object D:\_SMSTSVolumeID.7159644d-f741-45d5-ab29-0ad8aa4771ca. TSManager 19/06/2019 18:55:24 7816 (0x1E88) Updated security on object C:\_SMSTaskSequence. TSManager 19/06/2019 18:55:24 7816 (0x1E88) Set a global environment variable _SMSTSNextInstructionPointer=64 TSManager 19/06/2019 18:55:24 7816 (0x1E88) Set a TS execution environment variable _SMSTSNextInstructionPointer=64 TSManager 19/06/2019 18:55:24 7816 (0x1E88) Set a global environment variable _SMSTSInstructionStackString=27 TSManager 19/06/2019 18:55:24 7816 (0x1E88) Set a TS execution environment variable _SMSTSInstructionStackString=27 TSManager 19/06/2019 18:55:24 7816 (0x1E88) Save the current environment block TSManager 19/06/2019 18:55:24 7816 (0x1E88) Expand a string: %_SMSTSMDataPath%\Logs TSManager 19/06/2019 18:55:24 7816 (0x1E88) _SMSTSReturnToGINA variable set to: TSManager 19/06/2019 18:55:54 7816 (0x1E88) SMSTSUninstallCCMClient variable set to false TSManager 19/06/2019 18:55:54 7816 (0x1E88) _SMSTSCaptureMedia variable set to false TSManager 19/06/2019 18:55:54 7816 (0x1E88) The action (Upgrade Operating System) initiated a reboot request TSManager 19/06/2019 18:55:54 7816 (0x1E88) Not in SSL TSManager 19/06/2019 18:55:54 7816 (0x1E88) **************************************************************************** TSManager 19/06/2019 18:55:54 7816 (0x1E88) Execution engine result code: Reboot (2) TSManager 19/06/2019 18:55:54 7816 (0x1E88) Task Sequence Manager ServiceMain finished execution. TSManager 19/06/2019 18:55:54 7816 (0x1E88) Task Sequence Manager execution terminated as system shutdown is in progress. Code 0x00000000 TSManager 19/06/2019 18:55:54 7816 (0x1E88) RegQueryValueExW is unsuccessful for Software\Microsoft\SMS\Task Sequence, SMSTSEndProgram TSManager 19/06/2019 18:55:54 7816 (0x1E88) GetTsRegValue() is unsuccessful. 0x80070002. TSManager 19/06/2019 18:55:54 7816 (0x1E88) End program: TSManager 19/06/2019 18:55:54 7816 (0x1E88) Stopping Task Sequence Manager service TSManager 19/06/2019 18:55:54 7816 (0x1E88) RegQueryValueExW is unsuccessful for Software\Microsoft\SMS\Task Sequence, SMSTSEndProgram TSManager 19/06/2019 18:55:54 4588 (0x11EC) GetTsRegValue() is unsuccessful. 0x80070002. TSManager 19/06/2019 18:55:54 4588 (0x11EC) End program: TSManager 19/06/2019 18:55:54 4588 (0x11EC)
Desktop Analytics - Internet Access Requirements
Hi, we have configured Desktop Analytics and connection health has the majority of devices as properly enrolled, however we have around 130 with a configuration alert of "Can't connect to the Connected User Experience and Telemetry endpoint (Vortex). Check your network/proxy settings" We don't have a proxy. With 90% working, I can't see how the network might be configured wrong. The one thing that stands out are that the majority of the 130 devices are either generic logons or autologon kiosks that don't have internet access. This leads me to does desktop analytics require a user to be logged on and for that user to have internet access? is it possible that as a fallback to this requirement DA tries to connect to the Telemetry with some sort of anonymous connection or using the device system account or maybe using a MECM service account. (does that MECM service account then need internet access?) If 2, i'd think I'd need to supply our firewall team with the exact requirements there, I can find all the endpoint contacts in doco, but what account do I have to get them to let through?
After sucsessfull OSD (Win10) trying to reinstall the client PC with the same TS fails
Hi, i created a TS do deploy Win 10 on a Client. All works fine so far. It´s a test enviroment so i done some changes at the TS and try to reinstall the same Client with the same TS. Result is, the PXE starts and the SCCM screen appears but the PC reboot and starts the previous installed Windows 10... Iam new to the SCCM so where can i find log´s to see whats going on (logname)Desktop Analytics - “Office 365 ProPlus”
We implemented Desktop Analytics in our environment. I'm missing the Option “Office 365 ProPlus” in the portal. The Video https://www.youtube.com/watch?v=-tAqDSRPW7Q shows at 21:57 an Option “Office 365 ProPlus” We do not see this option in our environment. Did we miss some configuration.
Regional Settings reverting to English United States
Hi All I am getting weird issue in my environment during OSD. I am having MDT integration with SCCM and using UDI wizard to get input for Keyboard Layout,UserLocale, TimeZone and Time Currency Format during imaging phase. Everything was working fine as is 10 days ago. Now what I notice is during OS imaging KeyBoard Layout is correct which is being selected during UDI (For instance lets say Danish KeyBoard Layout). As soon as OS imaging is completed whenever any domain user signs in, Keyboard Layout, Location and user locale is reverted to English (United States). My environment is having SCCM 2010 with ADK 2004 currently. I have tested behaviour with Windows 10 1803 and 1909, its all same behaviour. Any suggestions or inputs what can be wrong here. I am actually running out of troubleshooting steps to catch hold of this issue. Thanks in advance. Regards Anand Prasad
Ways to keep windows 10 up to date with CB/CBB releases using windows as a service
Hi Team, While i am working on WaaS feature in configuration manager CB 1702. I have few queries and need some pointers. Clients have Windows pro 1511 CBB. 1. When i try to use WaaS and create servicing plans using rings, does the new CB/CBB breaks customizations on the existing machines as part of Windows update? 2. While creating plan, i am observing that few updated are not listed with release CB and few doesn't listed if servicing plan is created for CBB (Business release). Is there any matrix which we can follow to understand if we select CBB , what we suppose to get as listed options to deploy as update and if we select CB, what all are the updates available? 3. I am exploring TS way to deploy updates for CB/CBB offline, while creating TS it expects 'upgrade package', where do i get this for CB/CBB. Suppose i have 1511 running on machines, where do i download 1607/1703 CBB to create those a package? None of article explains this.. 4. While using 'Servicing plan' rings, it downloads required update files from internet and those seems encrypted (like 15063.0.170710-1358.rs2_release_svc_refresh_CLIENTProfessionalVL_VOL_x64fre_en-us.esd)..how do we extract these packages manually or is there any way to run these packages manually or as part of TS? 5. In CAS, multi pri site and secondary site scenario, what is the efficient way to implement WaaS . Do we need to create 'Servicing plan' rings in each PRI/SEC Sites or Creating Rings at CAS level would be enough? Any pointers will be much appreciated. Regards.
Issues with Capturing Windows11 25H2
I have been trying to capture an updated image from vsphere8 and sccm. I had zero issues with 22H2 and 23H2 but now I cannot get sysprep to pass generalizing. This error keeps coming up but I have tried most things the great Google had to offer. Any one else running into this issue?Microsoft Patching is not working until User logon to the newly imaged device
Hi All, I have a customer that they have two separate SCCM and WSUS environments in the same domain and they use SCCM for OS imaging and WSUS for patch updates. The problem is end user hast to logon to the device after imaging the OS using SCCM to kick start the patching process from WSUS. My client's understanding is that it should work without user logon to the device since GPO targeted to all authenticated users. Please also note that the computer objects and other settings are working without any issues. I would appreciate if anyone come across such a behavior and there is any workaround that we can do kick start the patching regardless of user login or is this behavior by design? Thanks, Dilan
