We are using Microsoft SCCM 2007 to deploy program packages in our network environment. One of the packages (MathType, in case anyone's curious) has a lot of file names with a plus symbol +
in them.
When a package is downloaded to a client machine, the files are pulled from the distribution point server via http. The distribution point runs IIS, which does not handle +
signs in URLs. The result is that the SCCM client receives a 404 from the server, and is unable to finish downloading or installing the package.
I would just rename all of the files with a +
in them, but the installer is expecting certain file names, so we need to retain the original naming scheme. Due to how our network environment is set up, we do not have direct control over the distribution point server, so we can't make any modifications to IIS that would allow +
symbols in URLs.
How can we distribute packages that include files with a +
symbol without breaking SCCM?
I've thought of the following workarounds, but would like to find a more elegant solution that doesn't require manually adjusting any package with +
symbols:
- Put the whole thing in a self-extracting zip/7z file, and download that from the distribution point
- Rename all of the
files+with+plusses
tofiles_with_plusses
, then manually change them back to the original name in the installation batch file once they're downloaded to the local cache
Is there a solution that actually fixes the problem, rather than working around it?
Is there a solution that actually fixes the problem, rather than working around it?
Depends entirely on how you define "the problem." As I see it, "the problem" is that someone decided it would be a good idea to include special characters in his software's file path, despite it being a bad idea to do so. (He's not alone, if it makes you feel any better... or worse.) As a result, you can't just pass those paths to IIS, because it rejects paths with certain characters by default, as a security measure (to protect against maliciously crafted urls).
In the general case, a possible "fix" to this that doesn't involve renaming the files is to disable this security feature in the application's web config (allow Double Escaping). But as that would leave you vulnerable to maliciously crafted urls, I'm not sure I see that as a fix, but rather a workaround with a big security hole attached. Since you can't do this, it's largely academic anyway.
Your basic options are change the IIS settings to allow paths containing a
+
, or somehow remove/obfuscate the+
in the path. Since you're unable to do the former, the only option you have left is the latter. For what it's worth, creating a self-extracting archive out of the troublesome application sounds like it would be easier to automate, so that's what I'd go with.