Peter33

The health check doesn't restore the shortcuts. It's probably a silverlight update, which is always a full installer. So the silverlight shortcuts will be back after every security update.

Did the machine policy cycle work correctly? There should be no visible deployments in the software center if the client can't communicate with the server. Is your Client Firewall possibly blocking the communication? If everything fails you can still try to repair WMI too on your client. Uninstall the client again, reboot, stop the winmgmt service, delete c:\Windows\system32\wbem\repository, start winmgmt, install the client again.

Well, we are just migrating to a new product at the moment. It's called helpline. The workflow thing is just a part of it. It's a complete IT Management solution.

Try to repair BITS on the Clients (stop BITS Service, delete C:\ProgramData\Microsoft\Network\Downloader, start BITS Service). If that doesn't help uninstall the SCCM Client, reboot and then push the Client again.

We have a bunch of Clients which are for testing only and include every hardware type in production at least 1 time. They run also mixed OS Versions, at least 1 of each in production. The Clients are grouped in their own test collection which will be used for testing every deployment before we release it to everyone. The testing is done by some Client Admins who have nothing to do with SCCM. The whole process is documented in an electronic workflow.

Well, don't know if the Client health check will restore the shortcuts, which i find hard to believe. I will try that tomorrow. You could still create a compliance rule for your Clients wich deletes the shortcuts if they are present.

Try to only use SMSSITECODE=S12 CCMLOGLEVEL=0 SMSCACHESIZE=2048 FSP=SCCM12 in the Client push properties. Then post the ccm.log from the Server and ccmsetup.log client.msi.log from the Client (rather as file Attachement than plain text ... easier to read with cmtrace . Just by the way, do your Clients have net Framework 4 installed?

Did you try to remove and readd the Management Point role on your Server? Just by the way: seen this "Invalid argument '/NOSERVICE" in your Installation log. Indeed you are not allowed to use this Switch in your Client push properties. You can only pass Arguments but no Switches there.

That looks nice and clean as it should be. I guess you did configure the client approval in your hirarchy settings to automatic approval for domain members?

All right, what are the locationservices.log and clientlocation.log telling you?

Add the following reg key before you enable bitlocker. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE] "OSEnablePrebootInputProtectorsOnSlates"=dword:00000001

Just a site note. MDT 2012 does not recognize the Surface pro as any kind of device. So the variables IsLaptop/Desktop/Server are all set to false. If you peform any steps based on this variables in your task sequence you need to add an additional switch there. Hope the next update of MDT will fix this.

Set the execution policy to remotesigned. If you downloaded the file directly to c:\temp... copy this file again locally to another file.

Silly question. Is S12 the site code of your Primary Server?

Limit the deployment by a collection which holds only Clients being serviced by this site. You can query that by chosing the AD site, OU, Default Gateway .... whatever meets your requirements.

Have you chosen to update the distribution points on a schedule in the package properties (datasource tab)? I would just delete the package and create a new one from definition. There is really no need to update the distribution points by a schedule for this package.

Well, like i said: it depends all on your detection rules. If you run a setup without scripted actions around, to adjust additional stuff like copying files or creating registry keys, which are used for detection rules, a regular uninstall trough add/remove programs should just work fine (in most cases). You should always test this before you send one of your apps to production. Software which is no longer needed on a machine will be uninstalled automatically with the uninstall action of the application in our environment. Normal users have no local admin rights to uninstall any software.

Create a log file with the additional switch /L*v c:\Windows\temp\installvmc.log Then post the log file. Your Installation command looks correct.

If you run the application deplyoment evaluation cycle, the Client will check if the application is installed, based on the detection rules defined in the deplyoment type. If the Application is mandatory, it will immediately try to reinstall the app, if it was not detected. So if the conditions of the detection rule will not clean up properly by the uninstall command, the Software will stay in the installed section, because the Client does not recognize that the app got uninstalled. I have seen this only with some old Java runtime Versions when they got uninstalled with the SCCM Client Center for 2007, on a 2012 client. The Problem was that the registry key under HKLM\Software\Microsoft\Windows\currentversion\uninstall has not been cleaned up and the detection rule was pointing to the product code. Also, if you define additional steps in your Installation script, like Setting registry keys or copying files, which are not part of the Setup themself, and base your detection rules on one of them, you also have to provide a uninstall script which removes these items again. A normal uninstall via appwiz.cpl won't work anymore and will leave your Client in this messy state. Check your appdiscovery.log to see what's going on. You can also run the cycle from the command line with this command. WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule “{00000000-0000-0000-0000-000000000121}” /NOINTERACTIVE

This will build you Computer Name with the first 4 chars of the model and the first 8 chars of the Serial number, seperated by a "-" and replacing all blanks (important for virtual machines, you don't want blanks . Keep in mind that the compuer Name has a max length of 15 chars. OSDComputerName=#Replace("#Left("%MODEL%",4)#"," ","")#-#Replace("#Left("%SERIALNUMBER%",8)#"," ","")#

Are you talking about regular packages or application? Packages have no detection rules, so their staus is based on successful execution of the deployment. Once it got executed successfully, it will not be reset again, execpt you chose to reinstall and the deployment fails. If you talk an application that will not return to be available/installable, most likely you detection rule is not configured properly or the uninstall Routine did not clean up correctly. Anyways, sometimes you just Need to press F5 in the Software center to update the views. That's actually the only "bug" in there. Everything else works just fine. They "available Software" grid is only showing new, not yet executed, Installations. Additinally it's listing also not installed applications.

Try "C:\ProgramData\Citrix\Citrix Receiver (Enterprise)\TrolleyExpress.exe" /uninstall /silent as uninstall command.

Well, that's exactly what's causing your problem. The behavior of slow apps got fixed with SP1. If you check your smsts.log during the app install, you will see, that the whole task sequnce is getting compiled again before every single application. So install the SP1 and you will be good.

Just run "vstor_redist.exe /q /norestart" as Installation command.

Funnily i was running into a similar problem today, while i was trying to reimage a Bitlocker encrypted Lenovo Helix with Windows 8 x64 in UEFI mode. You also can't use diskpart there, because the TS can't store the script file. So i tried a totally different approach by using the Storage Cmdlets of Powershell v3, which worked great. First i added the optional component WinPE-StorageWMI to my boot image. Then i added a command line step to the task sequence to replace the diskpart command. The powershell command to clean the disk looks like this. powershell -ExecutionPolicy bypass -command clear-disk -number 0 -removedata -removeoem -confirm:$false You should be able to translate your diskpart file into powershell. Just have a look at get-volume and set-volume commands. Here is the cmdlet documentation.