Peter33

Let the setup write an installation log to get a detailed error description.

Make sure you have all prerequisites for IE10 installed before you launch the setup. http://support.microsoft.com/kb/2818833/en-us Check out the KB's listed here.

Maybe you have a password changing policy activated in your environment and you have reached the grace period?

This folder structure sounds like an Install Shield installer. Run the EXE as Admin without proceeding the installation and check the %temp% folder of the Admin for the extracted MSI. Usually located in some cryptic subfolder. Just sort by creation date. You can also try isxunpack from this site. Does not work for every Install Shield version.

Yes, of course you can. Packages are the "old" way to deploy Software, like you did in SCCM 2003/2007. The application model is the new way to deploy Software, giving you some nice benefits like detection rules and dependencies. It's still up to you which way you go. Personally i prefer the application model when ever possible.

You can deploy every software as application and as package. It's up to you which model you prefer. The only limitation are are programs which will be used in the PE Phase of OSD, like BIOS updates. They have to be packages but without programs. You need to run them from a command line step. Windows 2 Go WIM files have to be packaes also.

I would not mess around with AutoIT at all. It always depends on what is actually going on on the users screen. The user interactions will mess it up unless u are freezing the users screen with AutoIT during the Installation. Not really what you want to do in prouctional environments. If you have the right tools like "Admin Studio" or "Wise Studio", repackage the software and create an MSI from it. This is the best way to deal with such installers, unless they are also installing .Net assemblies. Alternatively you can create an optional application which installs in the system context and allows user interaction. Then brief the users to click the dialog during the installation.

I am usually just running a simple powershell command to ge the Product ID which will be the SoftwareCode property in the output. gwmi -namespace root\cimv2\sms -class sms_installedsoftware -filter "productname like '%part of the name here%'" If there is no valid value in the Softwarecode property, for example when the Setup is a freeware installer like "Inno Setup" (PDFmaker etc.), go for the registry like Shawn mentioned it and chose the DisplayVersion property. In your detection rule (registry) make sure to use "Version" instead of "string" and "greater than or equal to" instead of "equal". This will save you some trouble when you are using "supersedence" while testing the new applications.

Agent WARNING: Failed to evaluate Installed rule, updateId = {{B60E5F29-B534-48C2-885E-7DAF0C96DF72}.202}, hr = 80041017 The latest revision from May 13 of KB2919355 solved this issue. Just checked the TechNet posts and the problem is marked as solved. Guess i can get rid of the application now.

If you have the HyperV role installed on your Clients the automatic update via WSUS/SCCM will fail to apply udapte 1. Best way to deploy the update is to create an application.

Check out the client installation log file to see what's going on.

Yes, it will update the schedules depending on the runtime of the ADR. Maybe it will differ by 1 or 2 minutes.

Well, since "as son as possible" is not a valid schedule at all (it's not a specific time value), the ADR sets the time of the moment when it is finished. This value represents something that can be compared to maintenance window time values, for the easy math.

Try ... Monitoring -> Distribution Status -> Content Status.

Hi pvr, the correct task to disable is indeed "Delete Unused Application Revisions". Enable the other one again because it's doing no harm, but keep the "Delete Unused Application Revisions" task disabled. This one is the bad guy here, causing all the trouble Actually it took me some hours to figure out what was going on. Digging through all server and client logs. The only error i could find was the ciagent log error. So it was clear that the client was receiving a wrong policy for an application revision that wasn't even existing anymore. Since all clients together suddenly got this error from one day to another, the only remaining suspect was the maintenance task.

All right. This is being caised by a bug in the application version history cleanup maintenance task. (based on my opinion and not confirmed by Microsoft) Here is how i resolved it for our environment. First disable the Application History Cleanup Task in the maintenance tasks of your primary Server. Get the Application ID from the error line in the CIAgent.log and look up the application in the console. Edit the application by changing something, for examle the comment field. Save the changes and manually delete all Versions in the version history excet the newest. Update the distribution points. If the Application is referenced in any task sequnce, remove it from the task sequence and add it again. Wait for your clients to update their policies and you should be fine again. You might have to repeat the steps for additional applications though.

Please check your CIAgent.log files on the clients for errors like in the attached picture and report back if you got similar errors. I might be able to help you in this case.

Simple solution: just unplug the USB drive after you started the Task sequence. OSDPreserveDriveLetter only works for the OS drive. You could of course also add a script, which reassigns the drive letters for your data drives, at the end of your task sequence.

You can additionally set the version property in your product code detection rules.

Just happened to me this week while setting up a new secondary site. I updated two OS Image packages while the sync was not finished yet. The next day i seen a lot of error 13 messages in the despool.log. When i checked the inboxes\despoolr.box\receive directory of the DP i found 2 outdated .TRY files with a definitely wrong size. I just deleted these 2 files and redistributed the packages to this DP (content location tab in the properties of the package).

Sounds like a nested MSI, which performs the actual installation through an asynchron custum action. I would check the property table for possible switches to force a wait. At least you could create an Installation log to see what is going on. (msiexe /i ..... /L*v ...logname.log /q).

How do you create the local accounts during OSD? Scripted? If so you just could retrieve the SSIDs with a script and create the registry hives under HKEY USERS, then feed them with the registry keys and values for the local policies.

There is still the question where the 21 hour delay between ADR execution and depyoment creation comes from. Seems pretty strange to me. As soon as possible usually does not mean 21 hours.

Sorry, you won't find the reason in the smsts.log, because you deploy it as an application. Check out the appenforce.log. For Office installations i am always activating the logging in the config xml file. Makes trouble-shooting much easier. Especially applications are a little bit tricky during OSD,because the app model is pretty new, and there are obviously some bugs in combination with task sequences. This might be even caused just by a mismatch of the version of the appliation stored in task sequence, which might been deleted from the Version history by the maintenance task meanwhile. In that case just remove the app from your task sequence, clean up the version histrory and add the application again to the sequence. This is a behaviour i have seen after SP1 upgrade and it' still there with R2. At the Moment i have disabled the version history maintenance task t avoid it. It also had some other side effects. Of course your problem might be caused by something completely different.

Probably a stupid question, but is the time zone of your clients the same as your server?