Software Deployment

Could you try running it without -s? Occasionally you can glean more clues from running the entire install UI during deployment.

I tried running it with no switches; using only "muisetup.exe" as the command line.

A Google pitched up a few hits, one of which suggests installing "Microsoft Visual C++ 2005 Redistributable Library Pack", rebooting, then re-trying MUISetup. Another suggests running the executable from the ' %SystemRoot%\MUI' folder.

I tried installing "Microsoft Visual C++ 2005 Redistributable Library Pack", rebooting, then re-trying MUISetup. It didn't work.

As for running the executable from the ' %SystemRoot%\MUI' folder, how would I retool the package/program to do that? My choices are: 1) Network path (UNC name) and 2) Local drive on site server.

You can set SCCM to copy the file locally and execute it from there. Don't ask me how: I've never done it, having only recently been exposed to SCCM. I suspect the Help file might be the place to look for that information.

The setting you're talking about is in the advertisement properties. Set it to "download program from distribution point" when a distribution point is available locally in the Advanced client tab. The verbage might be a bit different with SCCM, but that will set it to download to the cache at %windir%\system32\ccm\cache and execute from there.

Actually, I normally set it to: "Download content from distribution point and run locally" (when client is connected within a fast (LAN) network boundary.

But this runs the downloaded (from distribution point) MUISETUP.EXE (C:\WINDOWS\system32\CCM\Cache\XXX), doesn't it? I was trying to see if there was a way to use the MUISETUP.EXE program in C:\WINDOWS\mui during the installation. Yes, there appears to be 2 MUISETUP.EXE programs.

There's nothing that will allow you to do that natively in SCCM. (As far as I know,) you could, however, always write a short script to copy the file first to whichever directory runs successfully, then execute the setup. At least with SMS 2003, I use scripts as programs very frequently because the default behavior just isn't... sufficient, sometimes.

I'm just getting started with packaging and deployment, so I haven't gotten into scripting yet. But I totally get you with regards to the default behavior being insufficient.

Hi guys!
Maybe this one helps?
http://support.microsoft.com/kb/935628

The version of the MUISETUP.EXE program I was trying to deploy is 5.1.2600.0. I did try replacing it with a more recent version, 5.1.2600.5512 (swiped from C:\WINDOWS\mui on a fresh XP SP 3 build), however the results remain the same.

Perhaps there is an even more recent version of MUISETUP.EXE available (i.e., more recent than 5.1.2600.5512). Unfortunately the linked article provides no details for obtaining a more recent copy.

Thanks for the link, though. I suppose I have stumbled upon a known issue.

What options do you have set for the deployment, such as 'Run as administrator', 'Run only when user is logged on' and so forth?

In the absence of logging, you could redirect its output to a file: MUISETUP [whatever] > %temp%\MUISETUP.LOG

EDIT:
This post http://blogs.msdn.com/michkap/archive/2006/12/28/1371979.aspx suggests that a log is created somewhere...! My guess would be %SystemRoot%

EDIT, EDIT:
http://support.microsoft.com/kb/246008

Environment
Program can run: Whether or not a user is logged on
Run Mode: Administrator
Allow interactive: No
Drive mode: UNC

Found the log (muisetup.log) in the %systemroot% directory. It doesn't appear to provide any detailed information at all.

I tried appending "> %temp%\MUISETUP.LOG" to the command line. It didn't like it (in other words, it didn't write a log to the specified directory).

When programs are timing out, it's because the host process is hanging open during the installation. I've run into a few applications that simply are not clean and do not always close their host process correctly, but those have been blessedly few. What I've found to be much more likely is that the installer is attempting to display a dialog, be it an error message or a warning or what have you to the system account. Since the dialog box cannot be interacted with by the user, it appears that the installation is just hanging.

I would try running the same program, but allow interactivity, and see if anything untoward happens. While it's running, take a look at the setup process (looks like muisetup.exe) with procmon, and see what it's attempting to access, and especially if it's an open, unused process (at 0 CPU usage) or if it is looping on an action of some sort (at high CPU usage, usually 50% or higher.)

I tried running again from SCCM, this time with interactivity, but it still fails. Actually nothing pops up on the client screen, so I don't think that muisetup.exe doesn't even get off to a proper start (It shows up as 0 CPU utilization in the task manager).

I've tried so many variations of the installation. One thing which is consistent is this particular error message that has been showing up in the System log:

The signer NT Build Lab of the assembly C:\WINDOWS\system32\CCM\Cache\TOK0006E.5.System\JPN.MUI\i386\ASMS\6000\MSFT\VCRTLMUI\VCRTLMUI.cat was too short - minimal key length is 2048 bits.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.


Following the suggested link yielded no helpful or useful information.

Is it unusual to encounter so much difficulty in using one Microsoft product (in this case, SCCM) to deploy another Microsoft product (in this case, XP MUI Pack)?