Jump to content


narcoticmind

Established Members
  • Posts

    44
  • Joined

  • Last visited

Posts posted by narcoticmind

  1. Couple of ways.. one is the VBS/CMD way you already mentioned...

     

    I'd go with this:

     

    First, patch the MSI with MSP before the deployment, this way you don't have to deploy the MSP separately. This can be done as follows:

     

    1. Create folders 1_MSI, 2_MSP, 3_FINAL

    2. Copy the .msi to 1_MSI and .msp to 2_MSP

    3. Create Administrative installation point of .MSI to folder 3_FINAL:

    msiexec /a "C:\temp\1_MSI\package.msi" TARGETDIR="C:\temp\3_FINAL" /qb

     

    4. Apply the .msp to .msi:

    msiexec /a "C:\temp\3_FINAL\package.msi" /p "C:\temp\2_MSP\patch.msp" /qb

     

    5. Copy the 3_FINAL as the Application source files for your application, it should now contain the .msp also

     

    After this I'd check if I could do the registry modifications with ORCA to your existing .mst file.

  2. Can anyone tell me please- what will be the format of GUID, if I have MAK product key abcd-1234-abcd-1234-abcd-1234

    I try {abcd1234abcd1234abcd1234} but it is saying "Specify a valid GUID".

     

    Thanks in advance.

     

    MAK/KMS product keys don't have anything to do with MSI packages GUIDs...

     

    The easiest way for me to find the MSI GUID to be used in the application properties, is to introduce the actual .MSI for the GUI as shown above this thread (just click browse).

    Another way is to install the application and check for HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall and try to find the Key pointing to the installed application, there should

    be msiexec.exe /x {guid} command shown...

  3. You could give a shot with this:

     

    http://www.windows-noob.com/forums/index.php?/topic/892-deploy-software-through-ad-groups-linked-to-collections-in-sccm/page__st__40#entry24739

     

    Basicly you create two collections, one for the removal and one for the install and everything is handled through computer account's AD group membership.

    Depending on your environment (big, medium, small) you should see if there are any performance hits with this approach.

  4. If so one question when may I custiomize my Delault profile

     

    yes pretty much, you'd keep FAT applications in the build and capture image and everything else (customizations etc) in your deployment image - more info in the speaker notes of this presentation i did

     

    Actually, you don't have to leave everything else to your deployment image, you can do modifications for the default profile on your build also.

    It really depends what kind of customizations are needed.. for example, if you install applications in your build and need do clear those app's

    shortcuts from the desktop, you can do during the build.... Same goes for Windows Explorer settings for default user, and I'd think that'll

    go with the screensaver also.

  5. Just do the following during the Build And Capture TS:

    1. Run A Commandline: reg.exe LOAD HKU\Default %windir%\..\Users\Default\NTuser.dat
    2. Run A Commandline: reg.exe ADD HKU\Default\Somekey /v SomeValueName /t REG_DWORD /d SomeValue /f
    3. Run A Commandline: reg.exe UNLOAD HKU\Default

    This has worked for me, basicly every user setting is stored somewhere in the registry, you just need to find them. Googling helps.

  6. I'd like to hear some opinions too... so far what I've thought of:

     

    Workstations / Servers in production:

    • One ADR and Collection for certain product, fully automated deployment (reboots also), contains only the updates NEEDED >= 1, SUPERSEDED = NO
    • One ADR and Collection for certain product, partially automated deployment (admin or some one else has to do the reboot), contains only the updates NEEDED >=1, SUPERSEDED = NO
    • Workstations / servers go to the correct collection based on Active Directory OU.

     

    Workstations / Servers in OSD:

    • One ADR and collection for certain product, fully automated deployment (reboots also), contains ALL the updates for the Product in case which are not superseded (for example all Windows 7 x64 SUPERSEDED = NO)
    • Workstations / Servers go to the correct collection by including the Build / Install collections to OSD Update collection

     

    ADRs run every month after the updates are synchronized and get deployed right away.

     

    Thought on this approach?

  7. I'm not going to install using VBS. The SCCM Application will do the thing for the msi installation. Is the copy of the lic file I need to get working within an Application.

     

    And that's what the vbscript could accomplish for you.. just wrap the msi installation in to the vbscript and add the copying of files to the same script. Use detection method by combining the msi's product code and existence of the .lic file.. pretty simple.

     

    My idea is that you WRAP the whole installation in to a single script that does the exact thing you're aiming for.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.