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

Hi there, Recently we upgraded from SCCM 2012 to 1606 Current Branch. Most clients are updated successfully. I have some of them that are Failed. As show here: However, when I look at the details, it's hard to understand why. The correct client version should be: 5.00.8412.1307 In this screenshot you can see some clients that have the Failed status. Client Version Reported From DDR has the correct version. Client Version Reported From FSP/MP has the wrong ersion. Many of the clients in that list both have wrong version and all of them have a different reason for the failure. Some of those are: 0x80072ee7,Unknown Error (-2147012889) - Failed to download file over WINHTTP at address. 0x80004005,Unspecified error - Invalid ccmsetup command line. 0x80200065,Unknown Error (-2145386395) - Failed to download files through BITS at address. 0x80004005,Unspecified error - Failed to find an available source. 0x00000000,Success - Cannot install prerequisite file 0x00000000,Success - Failed to find an available source. And so on... How to tackle these issues? What is your experience with client upgrades? I don't use Client Push... I've let CM deploy the new version automatically after the upgrade.

This issue is very annoying. My workaround is to show the mouse pointer location when hitting the CTRL key. F8 in CMD type main.cpl With the TAB key you have to find the option to show the location when hitting CTRL.

I deploy all mu applications with a Powershell script. Even if it's an MSI, I use the same Powershell script to deploy application. This makes it easy to add any aditional steps to be performed, like copying files, adding reg keys, showing dialogues/warnings, prompts to close processes before proceding, etc... Is it an MSI that you try to install?

Does anybody have an idea? Where can I start to troubleshoot this?

Hi, I have a couple (random) devices where I cannot install software. Not all software: only a couple applications As soon as user clicks on Install, the download is at 10% (immediately) and not downloading anything. -> It doesn't start from 0%. It jumps instantly to 10% I've cleared the cache folder just in case. When I start installation, download is immediately at 10% but no folder is created in the cache. I've uninstalled the client and reinstalled again. Same issue. -> uninstall and install work just fine The boundaries are configured correctly. I've redistributed the package again, to all DP's. I've checked that the BITS service is running on the device. Again, some other software do work fine. No problems there. I keep seeing this error in DataTransferService.log CDTSJob::HandleErrors: DTS Job '{GUID}' BITS Job '{GUID}' under user 'S-1-5-21-....' OldErrorCount 7492 NewErrorCount 7493 ErrorCode 0x80070003 80070003 translates to "The system cannot find the path specified." However, not sure what to do with it or how to troubleshoot. Any suggestions?

Nice, please do tell me if it's any better. I'll plan an upgrade in one or two months. If you deploy Windows 10 than it's probably the Cumulative Update that's taking too long. I really don't understand Microsofts logic in implementing Cumulative Updates in a professional environment. That means that all clients have to download approx. 1GB only to install a small portion of the update. Ridiculous! I hope the new "Express Updates" will be an improvement in the new release of Current Branch.

That error translates into "The system cannot find the file specified". Now this can either be related to a network issue. The content is is not available on the DP: Distribute content or (most likely) your Network Access Account is not properly configured. Check out this here: https://prajwaldesai.com/task-sequence-failed-error-code-0x80070002

You can either use Powershell or a simple cmd command to enable the feature. I enable the feature during OSD. Copy the sxs folder from your source media (Windows 10, Windows 8.1, etc...) You cannot use the sxs folder from Windows 8.1 in Windows 10 for instance. The folder is located in x:\Sources\sxs (x = drive letter) Because I do it during OSD, I've created package containing the script and the sxs folder. Now either create a Powershell script with this in it: Enable-WindowsOptionalFeature –Online –FeatureName NetFx3 –All -LimitAccess -Source $PSScriptRoot\Source\sxs Or you can create a bat file with this in it: DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:d:\sources\sxs -> No need for a bat file if it is via OSD. You can then just add a "Run Command Line"

Yes I did that. Actually, the problem is solved now. I've re-created the Boot Image and this time it works.

I'll ask this question Technet later today. I hate to say it, but this forum is not what it used to be I rarely get a reply on my topics over here.