dinci5

Because the Icon table is already present in your MSI. You even selected it on your left side.

Hi,I have upgraded my lab to 1810 recently. And I think something is broken.The lab is setup in Hyper-V and used to work fine before.Ever since I've upgraded, my deployments are not working.A couple of errors from smsts.log:"Network access account credentials are not supplied or invalid.""Failed to get client identity (80004005)""failed to request for client""SyncTimeWithMP() failed. 80004005.""Failed to get time information from MP: http://LAB-CFG.Domain.com."Now, I've seen this error before in our Live environment and back then it was an issue with the date and time on the clients.I solved that with a pre-start script that syncs the time.However, in this case, the VM's time is correct. So it's not a problem with the date and time.The Network Acces account is obviously configured correctly. Tripple checked this.I can ping the server. I mapped a network share with the Network Access account from WinPE successfully, password is not expired...I've also reset the password of the NAA and tried with that. But no changes here as well.I've checked certificates of the DP and the Boot Media. Both are still valid.I have this problem when I PXE boot and when I boot from a Boot Media ISO.I even created a new Boot Image, distributed content and Updated DP.PXE and new ISO still same issue.I've then created a new DP on a separate computer (used to be a role on the Site Server) but still same issue.Boundaries are correct.I don't see errors in the Component Status.Any idea where I have to look next?It's in a lab, so not critical, but I've put a lot of effort into setting up this lab and don't really want to start from scratch.Also, this makes me think, it started after I've updated to CM 1810. I'm afraid this might happen in Live env as well.So I want to sort this out before I upgrade my live environment. smsts.log file attached smsts.log

I don't like that method. I just use the recommended driver method.

You could remove the content from your DP's and then re-distribute again. Properties of the Application > Content Locations > Select one by one and Delete. This should do the trick.

Don't use the shutdown tool. Use Powershell App Deploy Toolkit instead. The shutdown tool might be seen as malicious by some AV There is even a built in function in the toolkit called "Get-PendingReboot" which you can use to check whether there is actually a reboot pending an then use a notification popup to notify users or force a shutdown.

Hi, How do you guys manage the Surface Pro drivers? We have a couple hundred Surface Pro 3 and Surface Pro 4 devices. Now that I want to deploy W10 1709 I had a hard time figuring out which drivers to download for this version due to the stupid and extremely confusing versioning of these driver packages. For instance, the latest driver pack for the SP 4 is called "SurfacePro4_Win10_15063_1704201_0.zip". So by looking at the filename you would guess that it's only for W10 1703. Turns out, according to this blog post, it states that the driver pack with that name is for W10 1709 or above. Anyway... Do you import the drivers from the ZIP and create a driver package? If so, how often do you update the package? I did that before and quite often I had issues with the devices (not returning from sleep, freezing at Surface logo, etc...). Or do you guys just deploy the MSI? This would be much much easier. But not sure whether this is best-practice. Another question is: When installing the MSI or the driver package, I also install the actual firmware (UEFI, Touc, etc...). Reinstalling the same device will install the firmware again. Is that harmful? I thought that the Firmware can only be installed once, but I see the Firmware upgrade screen every time. I can't install the drivers via WSUS as we don't have Server 2016. And I don't really want to do that migration yet.

Yes yes, that's what I do. I change the key to the KMS key and I don't get the OEM issue anymore. Now I'm still struggling with the issue where the TS doesn't complete successfully and CM Client is messed up. The Windows upgrade is successful. It's also reflected in the Setupact.log It all starts here:

I'm starting to hate SCCM. This product has so many bugs it really isn't fun anymore. Now all my upgrades hang at setupcomplete.cmd until it times out. After OS starts the CM client is stuck in Provisioning Mode. The OS is upgraded though and it works fine. But the TS never completes successfully. Only thing I see in smsts is this: Succeeded loading resource DLL 'C:\WINDOWS\CCM\1033\TSRES.DLL' TSManager 11/14/2017 10:28:08 AM 5952 (0x1740) Failed to create an instance of COM progress UI object. Error code 0x80040154 TSManager 11/14/2017 10:28:08 AM 5952 (0x1740) Timed out waiting for ccmexec service to be fully operational TSManager 11/14/2017 10:58:17 AM 5952 (0x1740) 0, HRESULT=80004005 (e:\qfe\nts\sms\framework\tscore\utils.cpp,5348) TSManager 11/14/2017 10:58:17 AM 5952 (0x1740) Failed to wait for Ccmexec service to be fully operational (0x80004005) TSManager 11/14/2017 10:58:17 AM 5952 (0x1740) TS::Utility::WaitForCcmExec(g_hShutdownEvent), HRESULT=80004005 (e:\qfe\nts\sms\client\tasksequence\tsmanager\tsmanager.cpp,1343) TSManager 11/14/2017 10:58:17 AM 5952 (0x1740) Process completed with exit code 0 TSMBootstrap 11/14/2017 10:58:17 AM 5764 (0x1684) Successfully finalized logs to SMS client log directory from C:\WINDOWS\CCM\Logs TSMBootstrap 11/14/2017 10:58:17 AM 5764 (0x1684)

Upgrading from Pro. I'll have to use MAK keys then because those remote users rarely connect to our network so devices won't stay activated forever. That's why the OEM keys were ok for us. We don't use any features from from W10 Enterprise anyway.

From 1607 and 1703. I think I figured out what was going on. In Setupact.log I saw this line: "Client OS edition and OEM license detected and no enterprise edition detected, will not run SetupComplete.cmd" So the SetupComplete.cmd script didn't run which caused the TS to stop and the CM client to remain in Provisioning Mode. Due to the specific nature of the client they have devices with OEM licenses as well. This is because many employees work in remote locations (Africa, South America, Asia, etc...) and they purchase devices locally with OEM licenses. Those are then joined to the domain CM Client is installed manually and devices is encrypted with Symantec Endpoint Encryption. I did test on random devices where some of them were indeed activated with OEM license and others via KMS. Those activated via KMS worked just fine. Is there any way to change the Setup.exe command line string that's executed by the TS? I do append extra switches, like /ReflectDrivers, but can you actually change the default switches?

Ho do you deploy the application? Did you wrap it in a script? VBS, bat, PS? If so, you can easily append that command in the script.

Hi, I'm testing an Upgrade TS to Win 10 1709. I tested 4 devices now. On devices, all was working fine. Update was successful. On other two devices, the OS upgrade was successful, but after the OS boots again the TS doesn't complete successfully. I have two batch files in the Post-Processing group which are not executed. One of them just creates a txt file so I know it did run actually. In Software Center, the TS has status "Installing..." and it keeps spinning like that for hours. The smsts.log files is also not updated anymore after the last reboot. So the Setup command executed successfully, device rebooted, did the OS upgrade successfully, and when booted to the OS the TS just stopped. New Windows 10 works perfectly fine though. I can install other apps via Software Center as well without issues. Anyone has an idea where to look? Due to this, the status of the deployment is also not reported back to CM. If 2 out of 4 devices have this problem, I guess it's not a good sign. Of course I'll do some more testing but this is definitely not a good sign.

Here is a tip how to add an icon to 7Zip (or any other MSI that doesn't contain an icon): Download and install Orca. Right click on the 7Zip MSI installed > Edit with Orca in Orca go to Transform > New Transform Hit CTRL+T to add a new table. (or right click in the Table pane > Add Tables) Select Icon from the list. Click the Icon table and add a new row: Right click > Add Row Enter Row Name; Data: browse to a file that contains the Icon. I usually just browse to the application EXE of the installed application as it contains an icon but you can browse to an ICO file as well. Orca will read the Binary data of the file. Now go to the Property table and add a new row: Property: ARPPRODUCTICON Value: Name of the Icon row (in my case it's 7zFM.exe) The ARPPRODUCTICON property specifies the foreign key to the Icon table, which is the primary icon for the Windows Installer package. You can now either save the transform (MST) file and apply it during the installation or you can save the MSI. Best practice is to keep the original MSI and only save the MST file, but it's up to you what you'll do. You can now install your application with the MST file: msiexec /i "7Zip.msi" TRANSFORMS=7Zip.mst /qn

Is this only an issue if upgrading from 1610? I'm planning an upgrade from 1606 to 1702; This topic just scared the shit out of me. I wouldn't know what to do if it fails.

bump