none
What length limits on SCCM 2007 command line & can I reference Transform relative vs. absolute?

    Question

  •  

    These are the 2 lines I have tried:

    1) msiexec.exe /i AdbeRdr1010_en_US.msi /t xxAdbeRdr1010_en_US.mst

    #1 above gives no errors and installs just fine, but does NOT invoke the Transform.
    Yes, yes, I know, I can check on "AppDeploy.com" - but what I need to know is: Are there any special requirements for pointing to transforms with SCCM? I say that, because I saw a previous note that said, "For SSCM, you MUST use the FULL PATH to any transform, vs. using a relative location or a UNC" - but in SCCM docs I have not seen that specifically noted.

    2) msiexec.exe /i "AdbeRdr1010_en_US.msi" TRANSFORMS="C:\WINDOWS\system32\CCM\Cache\MHA0001E.3.System\AdbeRdr1010_en_US.mst”

     

    #2 above gives erorrs "Error applying transforms. Verify that the specified transform apths are valid." I verified - actually "cut-and-pasted" the whole line to be sure I targeted the exact (vs. relative) location of the Transform. The transform was just created, via Adobe's config wizard and is, as far as I know - valid.

     

    NOTE: IF I do happen to give a LARGE path, then the SCCM logs later show "path too long," regarding the length of the command line, so - What is the length limit regarding an SCCM Command Line (in a program/package)? I was unable to find a reference to the length limit, but it appears to be around 200 characters?

     

    And I found the below reference, which seems to indicate that SCCM does NOT care if I use a 'relative reference' vs. a full, absolute path to a transform file - but I've yet to get Adobe's "TRANSFORMS=" to work in SCCM. It's as if SCCM wants me always to use the "/t mytransform" vs. "TRANSFORMS=" -  (Note: I am running from a 'persistent cache' area, and so the working directory should not be having any issues - I have "use UNC" checked on the program/package but, obviously, on the command-line itself I have tried both absoulute/direct path as well as relative path - i.e., just give it "TRANSFORMS=mytransform.mst" (since the cache folder is where the thing resides [AND] I do have the program set to "download from the DP and run" vs. "run from the DP").

     

    Can anyone confirm that you have successfully applied transforms via SCCM 2007 using Adobe's "TRANSFORMS=" syntax?

    I will try re-creating the package; and manually copying a good/valid transform just to rule out that, but just want to know the SCCM command-line length limits and if anyone has SCCM Adobe packages succesfully using "TRANSFORMS="

    [Here's the prev SCCM thread showing relative path to Transform should work]
    Hi Lokesh
    sorry i took a while
    the command line i use is msiexec.exe /q ALLUSERS=2 /m MSIHPSJR /i "AcroRead.msi" TRANSFORMS=mytransform.mst

    if you run a standard install on a machine the msi package is extracted to the install folder in program files, use the transform creator provided by Adobe to create your own transform file, put the transform file in the same folder as the msi file, then create your package. i create a new program within the package and use the command line as above.
    hope that all makes sense.
    Tony


    tnjman
    Wednesday, June 22, 2011 7:09 PM

Answers

  • I agree with Miguel.

    To summarize what you need to do, put the MSI and MSP(s) into a single package.

    Create a batch file and put it into the package source directory:

    msiexec /I "adobexyz.msi" PATCH="%~dp0adobexyz.msp" /q

    Use the name of the batch file (nothing more, nothing less) as the command-line.

    If you set the advert to download and execute, this will run from the cache fine.

    Done.

    As for the command-line length, don't know, never hit it. Just use a batch file instead if you have issues.

    Finally, the MSI you download from Adobe is a wrapper MSI. You should download the exe (ftp://ftp.adobe.com/pub/adobe/reader/win/10.x/10.1.0/en_US/AdbeRdr1010_en_US.exe) and use the MSI in it by running the following command-line:

    AdbeRdr1010_en_us.exe /nos_oC:\Reader /nos_ne

    nos_o specifies the output directory (which should not exist yet otherwise it will error out). No space between nos_o and directory path

    nos_ne tells it not to execute the install

    The resulting files in the specified directory contain the MSI you need to use.

    Also, make sure that you acquire the proper license to distribute Adobe Reader in your environment: http://www.adobe.com/products/reader/distribution.html. This is free and quick so don't whine :-), just do it.

    There is also a corpoate distribution guide from Adobe that covers the Adobe specific details. Additionally, there is custom transform creator also available from Adobe.


    Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys
    • Marked as answer by TNJMAN Thursday, June 30, 2011 2:30 AM
    Wednesday, June 29, 2011 9:07 PM

All replies

  • A lot to address in the post.

    First, MSTs do not have to fully qualified to be used, MSPs do however.

    The TRANSFORMS public property is not an Adobe syntax, it is a standard Windows Installer public property and yes, using it works works fine with Adobe Reader. However, the MSI package that you are using it against is not the correct one. You should download the Adobe reader exe installer and extract the proper reader MSI from it.

    Also, you should not directly path to a file in the local COnfigMgr cache because that path is necessarily guarenteed to be same.

    To answer your simple question, does this work: yes, I do it all the time at my customers.


    Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys
    Wednesday, June 22, 2011 9:19 PM
  • Thanks Jason - then, how do we address "direct path to an MSP" without directly addressing the 'cache' folders?

    I am very confused on that point. First off, if it is a HUGE package, then referencing \\mySCCMserver\someShare\some.msp will cause havoc, because we have TINY bandwidth lines - thus, the only way to effectively do these packages is to "download to local cache" (from the related DPs) and run them from that local cache; BUT, maybe running from the DP might be an option - should be okay, since the DP is on the local LAN. What do you think? Instead of "download and run from cache," would it be better to set packages to "run from the DP?"

    And then, for packages that might even have problems running from the DP, how on earth would we reference large patches (MSPs) in cache, without referencing direct folders? (assuming something forces us to have the need to run directly out of cache). It just seems like a BROKEN process, since the MST does NOT require 'full-direct path,' and yet, the patches/updates DO require full path. Seems like this is something that could (should?) be fixed - i.e., if I can reference my MST without full path, I should be able to reference the patches also without full path, since my working directory in cache is the SAME folder for both - maybe it's just me???

    And, finally, you never answered the question of "what is the SCCM command line length limit?" Seems it breaks down and fails at about 200 characters, which seems an unusual number - would seem the SCCM command line would allow 256 - and maybe it does and I counted wrong?

    Thanks for the info so far!

    Jeff


    tnjman
    Wednesday, June 29, 2011 2:08 PM
  • Oh, and as for your comment "[I] am not using the correct MSI package;" I don't understand your comment at all, because this IS [THE] package that we get from Adobe - is there something I am missing? Am I using maybe a 'generic Adobe MSI' installer, and I should use a more specific one?
    tnjman
    Wednesday, June 29, 2011 2:10 PM
  • You should include all the files needed for that installation in your package and use a batch file to kick off the installation. Using full path to the files (MST/MSP) is always a good idea.

    I would use something like this:

    pushd %~dp0
    msiexec.exe /i "AdbeRdr1010_en_US.msi" /qn TRANSFORMS="%~dp0AdbeRdr1010_en_US.mst” /lrew "%temp%\AdbeRdr1010_en_US"

     

    %~dp0 expands to the full path, so you should be ok with this.

    There is no need to reference any path from the cache. That even won't work as soon as the source version changes...


    Miguel Rodriguez
    Wednesday, June 29, 2011 2:20 PM
  • First off, you give an example using something I've never heard of - what is "PUSHD????"

    Please do not give examples, without full details.

    Secondly, I already pointed out that (in general) I am forced to "run from cache."

    Thirdly, whenever I run from cache and DO NOT give the 'full path' to the MSP (patch/updates), it fails; so, yes, FULL path is needed, unless you know some 'trick' I don't know?

    UNLESS I run completely from the Distribution Point and then do not do anything in cache.

    I asked before: is FULL PATH needed, and the 'experts' here said YES, it is needed for the MSP files.

    Now, granted, I could create a package using a single "psexec" command (psexec is a tool from the Sysinternals suite) and that also should work. Or, as I said, run from the DP. I prefer to run from cache, but I should be able to run from DP without any problems.

    Now, for those of you SCCM admins who need to push Adobe Acrobat Pro X (plus the patches), please note that putting the whole thing into a single SCCM command like:

    msiexec/i my.msi PATCH=patch1.msp;patch2.msp TRANSFORMS=my.mst

    did NOT work via SCCM, due to some Adobe limitation - Apparently, Acrobat X (the MAIN msi) must be installed FIRST; and THEN you can do an install command with the 2 patches listed, but as a separate program under the package that you create; i.e., a package containing 2 programs - 1st program (main msi); 2nd pogram (main msi with PATCHES=patch1;patch2, etc.) - where this 2nd program depends on the first program (i.e., for the 2nd program, click "Run this program first" and point to the 1st program - the main install program). Then setup your advert, so that you run the 2nd program (which will, in turn, run the first program). There also is a way, I'm sure, to do this with the "task sequence" thingy; but I'm not yet familiar with doing that, so 'chaining' can be done several ways, and I've used the above method without any major problems.

     So, what is this unexplained "pushd" that you referenced? Thanks.


    tnjman
    Wednesday, June 29, 2011 6:04 PM
  • Also, nobody has answered: What is the command-line length limitation in an SCCM 2007 program (within a package)?

    256 characters?

    200 characters?

    Thanks for all the great info!


    tnjman
    Wednesday, June 29, 2011 6:13 PM
  • I cannot tell the limitation for the program option. Maybe someone at MS call clarify that.

    Anyway - using a batch file you have no limitations.

    I still don't understand the reason you why you have to reference the cache folder. Could you explain that?

    btw: as i wrote in my earlier post, pushd %~dp0 during execution of the batchfile expands to the current path your batchfile was executed from. I use that to make sure I do not have any file not found problems.
    example: when you execute a batchfile from the c:\test folder it will expand to c:\test\
    So the batchfile has access to all files in that folder.


    Miguel Rodriguez
    Wednesday, June 29, 2011 8:48 PM
  • I agree with Miguel.

    To summarize what you need to do, put the MSI and MSP(s) into a single package.

    Create a batch file and put it into the package source directory:

    msiexec /I "adobexyz.msi" PATCH="%~dp0adobexyz.msp" /q

    Use the name of the batch file (nothing more, nothing less) as the command-line.

    If you set the advert to download and execute, this will run from the cache fine.

    Done.

    As for the command-line length, don't know, never hit it. Just use a batch file instead if you have issues.

    Finally, the MSI you download from Adobe is a wrapper MSI. You should download the exe (ftp://ftp.adobe.com/pub/adobe/reader/win/10.x/10.1.0/en_US/AdbeRdr1010_en_US.exe) and use the MSI in it by running the following command-line:

    AdbeRdr1010_en_us.exe /nos_oC:\Reader /nos_ne

    nos_o specifies the output directory (which should not exist yet otherwise it will error out). No space between nos_o and directory path

    nos_ne tells it not to execute the install

    The resulting files in the specified directory contain the MSI you need to use.

    Also, make sure that you acquire the proper license to distribute Adobe Reader in your environment: http://www.adobe.com/products/reader/distribution.html. This is free and quick so don't whine :-), just do it.

    There is also a corpoate distribution guide from Adobe that covers the Adobe specific details. Additionally, there is custom transform creator also available from Adobe.


    Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys
    • Marked as answer by TNJMAN Thursday, June 30, 2011 2:30 AM
    Wednesday, June 29, 2011 9:07 PM
  • Okay, thanks for at least trying - the message below (Jason's message) seems to answer most of it.

    To answer your question - I already told you, but I will say it again: I *must* reference the cache folder because, if I download the package to the user's local cache and then DO NOT reference the full path, then the MSP (patch/update) will FAIL. I hope that is clear enough. So, bottom line: If I do not give 'full path' to the MSP files (which are in cache), then the package will not install successfully.

    And you still do NOT answer my question: What is PUSHD? You mentioned PUSHD above, and I just want to know what that means. Thanks.


    tnjman
    Thursday, June 30, 2011 2:29 AM
  • Okay, to Miguel & Jason - thank you! I looked up PUSHD also, and it is apparently for storing the current directory. That explains it.

    I agree with BOTH of you - I will just use a batch file, if length is an issue - that was my plan, if command-line length or complexity was an issue.

    And apparenlty pushd may allow me to store the full path to the MSP files, without having to reference that full path directly.

    Again - thanks!


    tnjman
    Thursday, June 30, 2011 2:35 AM
  • Just use the command line in the batch that Jason mentioned. The variable %~dp0 does the magic; no need to use pushd.
    Torsten Meringer | http://www.mssccmfaq.de
    Thursday, June 30, 2011 7:04 AM
    Moderator
  • Will do, Torsten - thanks. Two more questions, then I will leave you alone (LOL)

    Question #1 - You (Jason) fully clarified about READER, but is it proper & okay regarding Acrobat Pro / Standard to use the AcroPro.msi (and AcroStan.msi) from the CD/DVD of the Corporate Copy that we purchased? Has anyone done that successfully - or is it better to pull down / extract the AcroPro.msi from Adobe's site? Of course, we have full license for x number of copies of Pro and Standard.

    FYI - My own experience follows:

    1) No problems - Acrobat Pro X, via manual install, using the "msi" from the CD/DVD, using a Transfrom created from Adobe's own tool

    2) Some Problems / Limited success - Acrobat Pro, via SCCM - using the "msi" from the CD/DVD, using a Transfrom created from Adobe's own tool

    3) Some problems / Some success, via SCCM - Acrobat Standard X with MSI from the purchased CD/DVD & Transform via Adobe's tools

    4) No problems - via manual install, Acrobat Standard X with MSI from the purchased CD/DVD & Transform via Adobe's tools

    5) No problems - Adobe Reader X, via SCCM - with package created from Adobe's MSI & Transform tools

    I also seem to recall that Acrobat Reader X was HAPPY with SCCM install [and] manual install using "one-command-installs-ALL" - in other words, a signle command installed both the product [and] the Patches/Updates.

    BUT, even with a Manual install, it appeared that Acrobat Pro X 'forced' me to FIRST install the 'base Acrobat Pro X' and THEN I was able to install the patches with a second command, using same MSI and "PATCH=".

    Question #2 - Is this true that TWO separate commands are needed to install Acrobat Pro X? (if so, it's not a big deal) - what is your experience?

    Thanks.


    tnjman
    Thursday, June 30, 2011 1:21 PM
  • FYI - CONFIRMED !

    Adobe Acrobat Professional X does FORCE you to do at least a TWO-LINE install!

    MSI (s) (A4:50) [15:05:25:132]: Product: Adobe Acrobat X Pro - Update 'Adobe Acrobat X (10.1.0)' could not be installed. Error code 1651. Additional information is available in the log file c:\AcroPro-Log.txt.

    Info 1651.Windows Installer does not permit updating of managed advertised products. At least one feature of the product must be installed before applying the update.
    C:\WINDOWS\system32\CCM\Cache\MHA00020.4.System\AcroPro.msi
    MSI (s) (A4:50) [15:05:25:132]: Windows Installer installed an update. Product Name: Adobe Acrobat X Pro. Product Version: 10.1.0. Product Language: 1033. Manufacturer: Adobe Systems. Update Name: Adobe Acrobat X (10.1.0). Installation success or error status: 1651.

    It's odd that Reader lets you do the whole install + updates/patches on the same line.

    I used the extended/expanded (but not 'verbose') logging:

    EXPANDED, BUT *NOT* VERBOSE LOGGING

    REM - Base pkg + transform

    msiexec /i "Acropro.msi" TRANSFORMS="Acropro.mst" /qn /l "c:\AcroPro-Log.txt"

    REM - THEN do the patches

    msiexec /i "Acropro.msi" PATCH="%~dp0AcrobatUpd1010.msp" TRANSFORMS="Acropro.mst" /qn /l "c:\AcroProPatches-Log.txt"

     


    tnjman
    Friday, July 01, 2011 2:36 AM
  • Just a FYI,

    I found the limit to be 171 characters including spaces. Seems like a strange number i know!

    Thursday, October 06, 2011 4:24 AM
  • I realize this doesn't solve your problem, but it does answer the question for others that may want to know how many characters you can fit into the Command Line.

    I just actually counted the number of spaces allowed in the Command Line area of a Program for a Package in SCCM and there 255 spaces there, which makes sense.

    • Edited by WBrady1965 Wednesday, August 01, 2012 4:50 PM
    Wednesday, August 01, 2012 4:49 PM