Questions[sccm](server)

I've been working with a particular .msi (AppleApplicationSupport.msi). I have installed it two different ways which I thought would be equivalent. However the results differ as follows.

PSEXEC -i -s cmd

Installing using a psexec -i -s cmd command prompt and running msiexec /i AppleApplicationSupport.msi results in the outcome I want:

• "Apple Application Support (32-bit)" shows up in "Add or Remove Programs"
• "Apple Application Support (32-bit)" can be uninstalled

MSI Deployment Type Installed by SCCM Client

Creating an MSI Deployment Type and installing it using the SCCM client yields the following results:

• nothing shows up in "Add or Remove Programs"
• SCCM does not detect that it has installed
• "Apple Application Support (32-bit)" app can be found using gwmi -Class Win32_Product, however, running $app.Uninstall() does not uninstall it.

What is the difference?

I thought that an MSI Deployment Type installed for a system was equivalent to running msiexec from a psexec -i -s cmd command line. Evidently, they are not the same.

1. What, exactly, is the SCCM client doing when it installs an MSI Technology deployment type for a system? Can I replicate that operation without SCCM involvement?

2. Is the SCCM client's execution of a Script Installer deployment type's installer really equivalent to a call to msiexec from psexec -i -s cmd? In other words, for script installer deployment types should I expect parity between msiexec run by the SCCM client and msiexec run from psexec -i -s cmd?

Added after kce's answer:

3. How does SCCM manage to install the .msi without it showing up in "Add or Remove Programs"?

It happens from time to time. I update a package and need to update the distribution point. We have multiple DPs, and usually everything goes through fine, however every once in a while, our main DP fails to update the package.

The content status log never says much about the failure. I don't have backend server access to the management points, or the DPs, I'm just the SCCM admin. I can check any logs in SCCM, run reports, and everything, but I don't know where to look.

In the past I've tried setting the "Disconnect Users from Distribution Point" setting on the problem package, both sub-settings to 0, but it doesn't really work for us. The problem just seems to go away on it's own after some time, but sometimes it takes several days. For the majority (really all, but there may be one or two I've overlooked) we set clients to "Run Program from Distribution Point" When deploying the program, not sure if that has anything to do with it, or what the root cause is.

Update

I've found a little more information in the reports, specifically the All Status Messages for a Specific Package at a Specific Site query. Using my package ID for the query, after the DP Update failed again, I did see one entry that stood out:

Distribution Manager failed to process package "Configuration Updates" (package ID = SOM00013).

Possible cause: Distribution manager does not have access to either the package source directory or the distribution point. Solution: Verify that distribution manager can access the package source directory/distribution point.

Possible cause: The package source directory contains files with long file names and the total length of the path exceeds the maximum length supported by the operating system. Solution: Reduce the number of folders defined for the package, shorten the filename, or consider bundling the files using a compression utility.

Possible cause: There is not enough disk space available on the site server computer or the distribution point. Solution: Verify that there is enough free disk space available on the site server computer and on the distribution point.

Possible cause: The package source directory contains files that might be in use by an active process. Solution: Close any processes that maybe using files in the source directory. If this failure persists, create an alternate copy of the source directory and update the package source to point to it.

I'm doubting the middle two causes for simple reasons

• The source folder isn't that deep to contain long filenames for NTFS, although I'll attempt to check for completeness.

• I can add files to the DP just fine, so it's not a filespace problem, other packages can be updated just fine.

What I wasn't expecting is that the 3rd cause says the source directory is in use somewhere. What difference would that make anyway? Isn't is just copying the files off the fileshare into the SCCM DP Share? Further throwing me for a loop b/c clients don't even access the source directory, it's pretty much just a staging directory for sccm to copy files from.

That just leaves the first cause, but that again goes back to the same thing: Other packages can update just fine.

I recently set up a new SCCM 2012 environment at my workplace and now we are creating our applications for distribution.

Some applications are set up using a script. When during testing, something was not right and the content of the application needs to be changed. The distribution point keeps on serving the old content to the clients.

I was wondering what the proper procedure is for updating the DP's when the content of an application changes. I have tried redistributing to the distribution points and deleting old revisions but to no avail.

So this sounds like a simple question but searching the internet I have been unable to find a list of what the different actions in the SCCM Client actually do.

On my machine it is called Configuration Manager and I am specifically talking about the actions tab.

Does someone have a list of each action and what they do? I would find it really helpful to have a reference in one place that I could point some fellow techs too.

I've been told that one should not sysprep a Windows image too many times... kinda like using a Nuralizer too many times on one person :) Can anyone provide additional information on this?

We like to periodically roll updates into the image we deploy with SCCM (so that deployment patching is reasonably short) and our process takes the last wim made, patches and syspreps it. Since we've done this to our Windows 7 image about half a dozen times so far, just hoping it doesn't cause some type of inbreeding situation...