Deploying Office 2016 and Office Proofing Tools Kit 2016 / Office 2016 language packs with SCCM 2012 R2

I recently deployed Office 2013 SP1 (and wrote a blog post about it). Now I got the honours to do the same for Office 2016. The procedure is theoretically quite the same, but with many different bugs and gotchas. The following procedure describes how to remove any previous versions of Office and corresponding Proofing tools & language packs and replace them with Office 2016 versions. I’ll dive right into the steps:

Customizing Office 2016

  • Got a copy of Office 2016 and extracted the iso. Our version is “Professional Plus” with Volume Licensing.
  • Fired up a command prompt and navigated to the extracted Office directory.
  • From here I ran “setup.exe /admin”  to launch the Office Customization Tool (OCT).
  • Customized the OCT settings according to our needs:
    • Setup/Organization Name
    • Setup/Licensing and user interface/Use KMS client key
    • Setup/Licensing and user interface/I accept the terms in the License Agreement, Display level: None, No tick in Competition notice, Tick for Suppress modal and No cancel.
    • Setup/Remove previous installations/Remove the following earlier versions of Microsoft Office Programs/Remove all (here’s a BUG btw, more on that later on).
    • Setup/Modify Setup Properties:
      • SETUP_REBOOT, value Never
    • Features/Modify user settings:
    • Features/Set feature installation states:
      • Everything gets installed.
    • Additional content/Configure shortcuts
      • For some weird reason, Office 2016 by default decides to put all of the shortcuts on the start menu WITHOUT a subdirectory – splattered all over the start menu. This is fixable by editing the shortcut entries. In Fig 2. below, I’ve added the path/directory \Microsoft Office 2016. You also have to add a “[“ in Start in, otherwise you can’t close the dialog box. It’s a “feature” (bug), see: https://support.microsoft.com/en-us/kb/2797938. While editing, you can also decide which shortcuts you want to put on the Desktop. In Fig 2, I’ve chosen to put the Excel shortcut on both the Desktop ([DesktopFolder]) and in the Start menu ([ProgramMenuFolder]\Microsoft Office 2016).
    • Update: More bugs, sigh. Skype for Business shortcut launches “Skype for Business Recording Manager” instead of “Skype for Business”. I’m getting very frustrated with all the bugs. See: https://community.office365.com/en-us/f/166/t/344410. Anyways, I corrected the mistake MS has made. In Fig 3 target should definitely not be Skype for Business Recording Manger, instead it should be “Skype for Business 2016”. At least so I thought. After this “fix” (and a test-deployment), my reward was the following message:

                   office2016_sfb_problem_with_shortcut

                   Fig 1. Problem with shortcut

      • Only solution (as I can see it), is to force-copy a “functional shortcut icon” during deployment. With functional I mean a shortcut that has been manually created from C:\Program Files (x86)\Microsoft Office\Office16\lync.exe. (You should also remove all the Skype for Business shortcut entries in OCT).
        • This shortcut will then be deployed as a dependency. See later chapter about dependencies.

                   Office2016_OCT

                    Fig 2. Office 2016 OCT.

                   Office2016_OCT_shortcuts

                   Fig 3. Skype for Business – example shortcut entry.

 

 

Deploying Office 2016/Removing Office 2013/2010

The deployment part was quite straight forward after the customization part was done. Well, so I thought. Instead I got to fiddle with SCCM’s supersedence and dependencies. More on that later on. As with Office 2013, I basically followed a (very good) guide from http://www.ronnipedersen.com/2012/11/how-to-deploying-microsoft-office-2013-using-configmgr-2012/ with some changes for our environment. In this case the changes were about uninstalling Office 2013 SP1, as a fully patched Office 2013 SP1 WON’T get uninstalled even though I’ve chosen to remove previous versions in the OCT (see my (unanswered) post at https://social.technet.microsoft.com/Forums/office/en-US/a664a0c7-c6b5-40a3-9e04-f347556d39a0/office-2016-oct-bug-office-2013-doesnt-get-uninstalledremoved?forum=Office2016setupdeploy). The remove previous version-feature works with Office 2010 however, which means I don’t have to create a supersedence relation for that version (luckily).

 

Checking parameters for Office 2013 uninstallation:

In order for Office 2013 SP1 to be silently removed via SCCM before you install Office 2016, you have to be sure that the uninstall string is correct and a custom xml-file is in place. I’m already using “custom.xml” (together with OCT) for the installation part, so I’ve created a custom2.xml for the uninstallation part. (The reason for this is also a bug, see my Office 2013 deployment post). This file contains only the following information:

<Configuration Product=”ProPlus”>
<Display Level=”none” CompletionNotice=”no” SuppressModal=”yes” AcceptEula=”yes” />
</Configuration>

You’ll then use this xml file when you specify the uninstall string for Office 2013 SP1 in SCCM. See https://weikingteh.wordpress.com/2013/09/12/uninstallremove-office-2013-with-configmgr-2012/ for details. If you don’t specify a xml file, the uninstallation won’t be silent. This in turn means it won’t be successful.

 

Supersedence

With all the parameters done, you can now deploy Office 2016 using Office 2013 as Supersedence (see screenshot below):

Office2016_deployment_supersecence

Fig 4. Supersedence.

 

All of the fields aren’t visible in the screenshot, but the fields are:

This application supersedes the following applications:

Application: Microsoft Office 2013 SP1
Old Deployment Type: Microsoft Office Professional Plus 2013 SP1 installer
Replacement Deployment Type: Microsoft Office Professional Plus 2016 installer
Active: Yes
Uninstall: Yes (Tick in the box)

That’s it! All the other options are the same as with a regular deployment, you just add the Supersedence-information (so Office 2013 SP1 can be successfully removed while installing Office 2016). This would not be successful without having specified the correct uninstallation information/parameters for Office 2013 SP1.

A general rule of thumb when using supersedence is that you must have the correct uninstall information specified for the application that will be superseded!

 

Update! I had problems deploying Office as “available”. (“Required” was working ok though). I always got the message “Past due – will be updated”  in Software Center (see Fig 5). This on the other hand made Office upgrade itself without user interaction, which was not acceptable for a deployment that was made available (NOT required).

Office2016_deployment_software_center_past_due-will_be_updated

Fig 5. Past due – will be updated.

After some googling I found out it was related to the supersedence settings. Don’t know if you can call this a bug, but at least it was working better if I followed this advice:

“Regarding the issue where you have set the application to AVAILABLE in the deployment, however the application uninstalls and upgrades without user interaction, I have found a work around.

The cause of the problem seems to be when you are deploying an application to a collection the option “automatically upgrade any superseded versions of this application” is CHECKED and GREYED out. If you deploy the application BEFORE you have added the supersedence, this will NOT be greyed out and you will be able to leave it unchecked. Then add the supersedence rules.

Hope this helps

Kevin”

Source: https://social.technet.microsoft.com/Forums/en-US/1abcc581-1ee8-4929-8a2f-71c8843a257c/application-supersedence-not-working-as-i-want-and-expect?forum=configmanagerapps

I mentioned the word better because even now it wasn’t working 100% correct. I had to click “Install” in Software Center about 3-4 times (for all the dependent applications). This wasn’t acceptable, as the software (and all its dependencies) should install with just ONE click. Well, I found the solution to this dilemma myself – just leave one checkbox unticked. (See Fig 6).

Office2016_deployment_supersecence_do_not_allow_to_see_what_supersedes

Fig 6. Supersedence checkbox.

With all this done, the deployment was running smoothly with just one click (“Install”) in Software Center.

 

 

Customizing Office Proofing Tools Kit 2016

This is actually the exact same procedure as for Proofing Tools 2013. I’ll copy/paste the information from my previous blog post:

We are using a Proofing Tools “CD” which include all of the proofing tool languages. Proofing Tools doesn’t/can’t change the UI language btw, only check the spelling. With this CD, there’s no need to separately download each proofing tool language. After some googling I stumbled upon http://www.msfn.org/board/topic/149212-office-2010-proofing-toolkit-silent-installation/ which seemed useful. Once again I’ll share my configuration so you don’t have to scratch your own head. First off, there’s NO “setup.exe /admin” on this cd/iso. You have to manually specify the languages (proofing) you need. The file you need to edit is located on the extracted iso, in my case \Office_2016_Proofing_Tools\proofkit.ww\config.xml. My file looks like this:

<Configuration Product=”Proofkit”>

   <Display Level=”none” CompletionNotice=”no” SuppressModal=”yes” AcceptEula=”yes” />
  
   <COMPANYNAME Value=”Abo Akademi” />
      
   <OptionState Id=”ProofingTools_1053″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1030″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1035″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1036″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1031″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1032″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1040″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1044″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_2068″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1045″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1049″ State=”local” Children=”force” />
   <OptionState Id=”ProofingTools_1048″ State=”local” Children=”force” />
          
   <Setting Id=”SETUP_REBOOT” Value=”Never” />
  
</Configuration>

This bypasses all prompts in the setup process and installs 12 proofing languages. I’m not going to list the languages here (OptionState Id values), as there’s a table is available at: http://technet.microsoft.com/en-us/library/cc179219(v=office.15).aspx . That’s it for the configuration – now ready for deployment.

Source: http://technet.microsoft.com/en-us/library/ee942200(v=office.15).aspx plus all the forgotten ones…

 

 

Deploying Office Proofing Tools Kit 2016/Removing Proofing Tools Kit 2013/2010

Again, this information is already available in my previous blog post about deploying Office Proofing Tools 2013 SP1, so please have a look there before you continue. The difference in the 2016 version is that I will use different dependencies so that Office and the language packs will be installed before proofing tools is installed. I’ll also use Supersedence the same way I did with Office 2016 above.

 

Checking parameters for Proofing Tools Kit 2013 SP1 uninstallation:

First off, I’ll copy/paste information about the installation:

Edit “programs” tab. The installation command should now include our custom.xml instead of the MSI-command. The command I used was: setup.exe /config \\sccm2012r2\Software\Office_2013_Proofing_Tools_with_Service_Pack_1\proofkit.ww\config.xml.  ( /config .\proofkit.ww\config.xml is an easier/better syntax, btw)

Ok – now you just have to add the uninstall information with a custom UNintallation xml-file. This is also the same procedure as with the Office 2016 deployment. Anyway, I created a custom2.xml file in the same location as mentioned above. It includes basically the same information as the Office 2013 SP1 uninstallation xml-file:

<Configuration Product=”Proofkit“>
   <Display Level=”none” CompletionNotice=”no” SuppressModal=”yes” AcceptEula=”yes” />
</Configuration>

…and for the uninstall program string I’m using: setup.exe /uninstall Proofkit /config .\proofkit.ww\config2.xml

There you have it. Both the install and the uninstall information are now specified. You can now go ahead and make the same Supersedence rules as with the Office 2016 deployment:

Office2016_proofkit_deployment_supersecence

Fig 7. Office 2016 Proofing Tools Kit – Supersedence.

Only thing that isn’t fully visible in the screenshot above is Application: Microsoft Office Proofing Tools 2013 SP1 – multilanguage.

 

You can now do the same thing with Office 2010 (proofing tools) if you want to uninstall/remove that version prior to installing proofing tools 2016. You’ll then add another supersedence rule so that BOTH Office 2010 proofing tools AND Office 2013 proofing tools will be superseded (both should then be in the list in Fig 7).

(I also specified the uninstallation information for Office 2016 (proofing tools) already, so I can (hopefully) use the same procedure with future versions of Microsoft Office).

 

 

Deploying Office 2016 language packs/Removing Office 2013/2010 language packs

Some people are also using language packs with Office so I had to figure out a way of uninstalling/replacing these with the 2016 versions. Luckily, Microsoft is using quite the same syntax as with proofing tools, so the task was actually quite simple. You start with the same procedure – checking for a valid config.xml file for installation and uninstallation. The difference here is that you don’t need any specific codes for the language(s), as one language pack only installs one specific language. Another nice thing is that you can use the SAME xml file for both the installation and the uninstallation. The custom.xml for the Swedish language looks like this for example:

<Configuration Product=”OMUI.sv-se“>
<Display Level=”none” CompletionNotice=”no” SuppressModal=”yes” AcceptEula=”yes” />
</Configuration>

That’s the only thing you need to add/edit to make it silent. The paths for the files are a bit different than with Proofing tools though. The xml file is in .\omui.sv-se (or omui.xx.xx for your own language). The MSI-file used for deployment (or actually only for getting the product code) is in the same directory. The installation and uninstallation strings are also a bit different. Let me show you some screenshots and whatnot from SCCM;

First off you create a new application and make it think it’s going to use a MSI file for installation. You do it like this only to get the detection method/MSI product code.

office2016_lang_pack_create_new_application_sccm

Fig 8. Create Application Wizard.

Use the path:

\\yoursccmserver\yoursoftwarestash\Microsoft Office 2016 Multilang Pack Swedish\OMUI.sv-se (or similar for another language) and select the file OMUI.msi

Then just next, next, next through the wizard.

 

After this, you edit the Deployment Type. First off, go to the Content location. This path will be wrong (as the msi file is located in the OMUI.sv-se -directory). Please REMOVE “OMUI.sv-se” from the content location path. That’s it for content.

office2016_lang_pack_content_sccm

Fig 9. Office 2016 Swedish language pack content location.

 

Then you move over to the “Programs” tab. Here’s where the magic happens. Remove all the text/strings from installation program and uninstallation program. Replace the text with the one from Fig 10 below.

office2016_lang_pack_programs_sccm

Fig 10. Programs tab. Same xml is used for both installation and uninstallation (even though it got cut off in the screenshot).

In case you want to copy/paste, the strings are:

Installation program: setup.exe /config .\OMUI.sv-se\config.xml
Uninstall program: setup.exe /uninstall OMUI.sv-se /config .\OMUI.sv-se\config.xml

 

Sources:

http://www.itninja.com/question/how-to-install-office-language-pack-2010-unattended
https://technet.microsoft.com/en-us/library/cc179145.aspx
http://www.techygeekshome.co.uk/2012/11/office-2010-language-pack-deployment-in.html

 

You can now do the same thing with Office 2010 language packs if you want to uninstall/remove that version prior to installing the 2016 language packs. You’ll then add another supersedence rule so that BOTH Office 2010 language pack AND Office 2013 language pack will be superseded.

 

 

Dependencies/Finalization

There you have it. You’ve created separate SCCM applications for Office 2016, Office 2016 Proofing tools and Office 2016 language packs. That’s very nice and all, but you probably don’t like deploying all three applications separately, now do you? Well, this is where dependencies comes into play.

In my final deployment I ONLY deploy Office 2016 Proofing Tools. Office 2016 (main office application) is a dependency of Proofing tools, and so are the language packs. See Fig 11 for details.

NOTE! Create THREE SEPARATE dependency groups, otherwise there will be an “OR” statement instead of “AND”. I learned this the hard way when the language packs wouldn’t install. See the right and the wrong way to create the dependencies below:   

office2016_dependency_new_sccm

Fig 11. Office 2016 Proofing Tools dependencies, the CORRECT way.

 

office2016_dependency_old_sccm

Fig 12. Office 2016 Proofing Tools dependencies, the WRONG way.

 

Update! As there is a bug with the Skype for Business shortcut icon, the shortcut will also be deployed as a dependency.

  • First, create a new directory for your application (script) on your sccm server. Call it “Office2016-Skype for Business-shortcut” for example.
  • Copy the Skype for Business 2016-custom shortcut (created in the Customizing Office 2016 part) to this directory.
  • Create two new PowerShell script files in this directory;
    • Name the scripts Office2016-Skype for business-shortcut.ps1 and Office2016-Skype for business-shortcut-uninstall.ps1 for example.
      • Contents of Office2016-Skype for business-shortcut.ps1:

copy “Skype for Business 2016.lnk” “C:\Users\Public\Desktop\Skype for Business 2016.lnk”
copy “Skype for Business 2016.lnk” “C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Office 2016\Skype for Business 2016.lnk”

      • Contents of Office2016-Skype for business-shortcut-uninstall.ps1:

del “C:\Users\Public\Desktop\Skype for Business 2016.lnk”
del “C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Office 2016\Skype for Business 2016.lnk”

 

Create a new application using the following information:

  • Create Application
  • Manually specify the application information
  • Name: whatever you like
  • Deployment Types:
    • Type: Script Installer
    • Manually specify the deployment type information
    • Name: whatever you like
    • Content location: wherever you store your applications, in a subdirectory called “Office2016-Skype for Business-shortcut” for example
    • Installation program: powershell.exe -executionpolicy Bypass -file “Office2016-Skype for business-shortcut.ps1”
    • Uninstallation program: powershell.exe -executionpolicy Bypass –file “Office2016-Skype for business-shortcut-uninstall.ps1”
    • Detection method: Setting type: File System: C:\Users\Public\Desktop\Skype for Business 2016.lnk AND C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Office 2016\Skype for Business 2016.lnk exist.
    • Install for system, whether or not a user is logged on, hidden.

With all this done, create yet another dependency group. Add this newly created application to this dependency group. You then have a total of FOUR dependencies.

Source: https://tjindarr.wordpress.com/2012/05/04/application-dependencies-in-sccm-2012/

 

 

Summarization

Let’s sum it up:

  • Actual deployment “object” is Office 2016 proofing tools, which in turn use dependencies (main office application + language packs).
  • Office 2016 supersedes Office 2013.
  • Office 2016/2013 removes/uninstalls Office 2010 via OCT (no supersedence).
  • Proofing tools packages use supersedence to update themselves to the newest versions (2010 –> 2016,  2013->2016).
  • Language pack packages use supersedence to update themselves to the newest versions (2010 –> 2016,  2013->2016).
  • Office 2016 is a dependency of Proofing tools 2016, and so are the language packs (and the Skype for Business shortcut).
  • A shortcut for Skype for Business is created in the Start menu and on the desktop. (It is NOT created via OCT as it creates a faulty one).

 

And some screenshots:

office2016_software_center_install_status

Fig 13. Downloading all of the needed packages/applications.

The number of downloaded components depend on which Office-components SCCM detects on the client. (Is Office already installed and are only the language packs needed, for example). I’ve now changed the application catalogue name of the “main” application to something more convenient than “Microsoft Office Proofing Tools 2016 – multilanguage”. Currently I’m using “Office 2016 with proofing tools + swe & fi language packs”.

 

office2016_software_center_install_status2

Fig 14. Updating components. One done, seven to go.

 

office2016_programs_and_features2

Fig 15. Before Office 2016 deployment. Office 2013 SP1 (with Proofing tools and two language packs). Same components are installed if using Office 2010.

 

office2016_programs_and_features

Fig 16. After successful Office 2016 deployment. Same thing, new versions 🙂

 

Success! 🙂 (Finally… after many, many, many hours of testing)

 

BTW, feel free to comment if you find this post useful.

Advertisements

Deploying Matlab 2014a with SCCM 2012 R2

This time I’ll show you how I (silently) deployed Matlab 2014a with custom Toolboxes. There are a lot of customizations taking place for this to be fully working, but luckily I found a good starting point at https://sccmpackager.wordpress.com/category/matlab-deployment/. Thanks a lot to the author for the guide, couldn’t have done this without it.

Steps:

  • Copied the Matlab installation files to the SSCM server with directory name “Matlab R2014a”.
  • Edited files for silent installation (in the root of “Matlab R2014a”). First off was “installer_input.txt”. I made the following changes:

installer_input.txt

  • fileInstallationKey=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
  • agreeToLicense=yes
  • outputFile=c:\temp\matlabinstall.log (for logs on the client)
  • mode=silent
  • automatedModeTimeout=5000
  • licensePath=license_2014.lic (We’re using a network license. A license server is already running in the domain. License_2014.lic includes information with the license server IP and the available toolboxes for this license. This file was previously downloaded directly from Mathworks).
  • lmgrFiles=false
  • lmgrService=false
  • setFileAssoc=true
  • desktopShortcut=true
  • startMenuShortcut=true
  • Then you have to specify which toolboxes you are going to install. Just uncomment the ones for your license. Example:
    • product.MATLAB_Coder
    • product.Embedded_Coder
  • That’s it for the installer_input.txt. Moving over to “activate.ini”:

activate.ini

  • isSilent=true
  • activateCommand=activateOffline
  • licenseFile=C:\Program Files\MATLAB\R2014a\license_2014a.lic
  • activationKey=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
  • installLicenseFileDir=C:\Program Files\MATLAB\R2014a\
  • installLicenseFileName=license_2014a.lic

That’s it. These two were Matlabs own files. The following files are custom batch files for installation and uninstallation in SCCM. They are also located/created in the root of the Matlab source files.

 

install.bat

(I’ve modified/simplified the batch file from the guide above, as it was a bit too complicated and wouldn’t work).

@ECHO OFF
TASKKILL /F /IM iexplore.exe >NUL 2>&1
TASKKILL /F /IM winword.exe >NUL 2>&1
TASKKILL /F /IM outlook.exe >NUL 2>&1
TASKKILL /F /IM excel.exe >NUL 2>&1
TASKKILL /F /IM MSACCESS.exe >NUL 2>&1
TASKKILL /F /IM NOTEPAD.exe >NUL 2>&1
TASKKILL /F /IM POWERPNT.exe >NUL 2>&1

if not exist “C:\temp” md “C:\temp”

if %PROCESSOR_ARCHITECTURE%==x86 (

ECHO Installing Matlab R2014a 32-bit
ECHO Do not close this window. It will close when the install is finished.

:: Wait for 10 seconds
ping -n 20 127.0.0.1 > NUL

REM Main Install
“%~dp0setup.exe” -inputFile “%~dp0installer_input.txt” -activationPropertiesFile “%~dp0activate.ini”

) else (

ECHO Installing Matlab R2014a 64-bit
ECHO Do not close this window. It will close when the install is finished.

REM Main Install
“%~dp0setup.exe” -inputFile “%~dp0installer_input.txt” -activationPropertiesFile “%~dp0activate.ini”

)

REM Return exit code to SCCM
exit /B %EXIT_CODE%

 

It’s actually quite simple. The batch file runs setup.exe from the Distribution Point and uses installer_input & active.ini as input files during the setup. It also passes a “success code” to SSCM when finished. The original script however use:

if not exist “C:\Program Files\MATLAB\R2012a” md “C:\Program Files\MATLAB\R2012a”
xcopy “%~dp0license.lic” /y /e “C:\Program Files\MATLAB\R2012a\”

This step is unnecessary, as the licensing will work just fine without having to “manually” copy the .lic-file to the Matlab directory. Also, if the Matlab directory is present during the installation, the installation will FAIL. Yet again I learned the hard way after reading logs… Here’s an example from the clients c:\temp\matlabinstall.log:

(Nov 20, 2014 14:03:40) Error: Cannot install in the specified folder because there may be files remaining from a previous installation.

So yes, the Matlab directory can’t be created BEFORE the installation, period. I cleaned up the script/batch file (as above) and the installation went just fine;

(Nov 21, 2014 10:19:40) End – Successful.

 

uninstall.bat

@ECHO OFF
TASKKILL /F /IM iexplore.exe >NUL 2>&1
TASKKILL /F /IM winword.exe >NUL 2>&1
TASKKILL /F /IM outlook.exe >NUL 2>&1
TASKKILL /F /IM excel.exe >NUL 2>&1
TASKKILL /F /IM MSACCESS.exe >NUL 2>&1
TASKKILL /F /IM NOTEPAD.exe >NUL 2>&1
TASKKILL /F /IM POWERPNT.exe >NUL 2>&1

if %PROCESSOR_ARCHITECTURE%==x86 (

“C:\Program Files\MATLAB\R2014a\uninstall\bin\win32\uninstall.exe” -inputFile “%~dp0uninstaller_input.txt”

) else (

“C:\Program Files\MATLAB\R2014a\uninstall\bin\win64\uninstall.exe” -inputFile “%~dp0uninstaller_input.txt”

)

REM Return exit code to SCCM
exit /B %EXIT_CODE%

 

uninstall_input.txt

outputfile=C:\temp\matlabinstall.log
mode=silent
prefs=true

 

With all these files in place, the directory structure looks something like this (Fig 1):

matlab_dir_overview

Fig 1. Matlab directory on the SCCM server.

 

Deployment

Now that you have all files configured you are ready to start the actual deployment. Creating the Application in SCCM is very easy now that the underlying work is done. Just create a new Application, use script installer and fill in the desired information. For Deployment Type use script installer once again and use install.bat and uninstall.bat as arguments (Fig 2).

matlab_deployment_type

Fig 2. Deployment Type

For the Detection Rule I just used the Setting Type: File System (see Fig 3).

matlab_detection_rule

Fig 3. Detection Rule

With these settings in place you are finally ready for deployment. (Don’t forget to distribute your content before the deployment).

 

Here are some screenshots (Fig. 4 & 5) which shows that Matlab has been successfully installed (with the specified Toolboxes):

matlab_installed_win7

Fig 4. Matlab successfully installed 🙂

 

matlab_product_list

Fig 5. Matlab with specified toolboxes from installer_input.txt. (Screenshot is actually from the Matlab uninstaller). Yes, we do use a couple of Toolboxes…

 

There you go. Hopefully this will help someone else out there with their Matlab deployment dilemma 🙂

Deploying Office 2013 SP1 and Office Proofing Tools 2013 SP1 with SCCM 2012 R2

UPDATE: New blog post about Deploying Office 2016 available!

Link: Deploying Office 2016 and Office Proofing Tools Kit 2016 / Office 2016 language packs with SCCM 2012 R2

One of my tasks last month was to make Microsoft Office application packages in SCCM 2012 R2 which should be available in the whole University. The applications in question were Office 2013 SP1 and Office Proofing Tools 2013 SP1. This may sound a bit boring as it’s a very “mainstream” deployment. This was my first thought also, but I ran into a couple of problems I thought I’d share. I started out by reading a couple of basic guides and then customized according to my/our needs. None of the guides were fully working without tweaking however. Here are my steps:

Customizing Office 2013 SP1

  • Got a copy of Office 2013 with Service Pack 1 and extracted the iso. Our version is “Professional Plus” with Volume Licensing.
  • Fired up a command prompt and navigated to the extracted Office directory.
  • From here I ran “setup.exe /admin”  to launch the Office Customization Tool.
  • Customized the OCT settings according to our needs:
    • Setup/Organization Name
    • Setup/Licensing and user interface/Use KMS client key
    • Setup/Licensing and user interface/I accept the terms in the License Agreement, No tick in Competition notice, Tick for Suppress modal and No cancel.
    • Setup/Remove previous installations/Remove the following earlier versions of Microsoft Office Programs/Remove all
    • Setup/Modify Setup Properties:
      • AUTO_ACTIVATE, value 1
      • SETUP_REBOOT, value Never
    • Features/Modify user settings:
    • Features/Set feature installation states:

                    <Configuration Product=”ProPlus”>

                <Display Level=”none” CompletionNotice=”no” SuppressModal=”yes” AcceptEula=”yes” />
   
                <OptionState Id=”LyncCoreFiles” State=”local” Children=”force” />
                <OptionState Id=”GrooveFiles2″ State=”local” Children=”force” />
                <OptionState Id=”ExcelAddInPowerMapFiles” State=”local” Children=”force” />
                <OptionState Id=”ExcelAddInPowerPivotFiles” State=”local” Children=”force” />

                 </Configuration>

      • With this file edited (and saved) and the .MSP-file from OCT saved in \Office_2013_extracted\updates , I was ready to deploy.

Sources:

http://www.ronnipedersen.com/2012/11/how-to-deploying-microsoft-office-2013-using-configmgr-2012/
http://technet.microsoft.com/en-us/library/ee460874(v=office.15).aspx

and probably many forgotten ones…

 

Deploying Office 2013 SP1

The deployment part was quite straight forward after the configuration part was done. I basically followed a (very good) guide from http://www.ronnipedersen.com/2012/11/how-to-deploying-microsoft-office-2013-using-configmgr-2012/ with some minor changes for our environment. Nothing worth mentioning here though.

Remember to install all Office updates after the deployment!

 

 

Customizing Office Proofing Tools 2013 SP1

We are using a Proofing Tools “CD” which include all of the proofing tool languages. Proofing Tools doesn’t/can’t change the UI language btw, only check the spelling. With this CD, there’s no need to separately download each proofing tool language. After some googling I stumbled upon http://www.msfn.org/board/topic/149212-office-2010-proofing-toolkit-silent-installation/ which seemed useful. Once again I’ll share my configuration so you don’t have to scratch your own head. First off, there’s NO “setup.exe /admin” on this cd/iso. You have to manually specify the languages (proofing) you need. The file you need to edit is located on the extracted iso, in my case \Office_2013_Proofing_Tools_with_Service_Pack_1\proofkit.ww\config.xml. My file looks like this:

<Configuration Product=”Proofkit”>

    <Display Level=”none” CompletionNotice=”no” SuppressModal=”yes” AcceptEula=”yes” />
   
    <COMPANYNAME Value=”Abo Akademi” />
       
    <OptionState Id=”ProofingTools_1053″ State=”local” Children=”force” />
    <OptionState Id=”ProofingTools_1030″ State=”local” Children=”force” />
    <OptionState Id=”ProofingTools_1035″ State=”local” Children=”force” />
    <OptionState Id=”ProofingTools_1036″ State=”local” Children=”force” />
    <OptionState Id=”ProofingTools_1031″ State=”local” Children=”force” />
    <OptionState Id=”ProofingTools_1032″ State=”local” Children=”force” />
    <OptionState Id=”ProofingTools_1040″ State=”local” Children=”force” />
    <OptionState Id=”ProofingTools_1044″ State=”local” Children=”force” />
    <OptionState Id=”ProofingTools_2068″ State=”local” Children=”force” />
    <OptionState Id=”ProofingTools_1045″ State=”local” Children=”force” />
    <OptionState Id=”ProofingTools_1049″ State=”local” Children=”force” />
    <OptionState Id=”ProofingTools_1048″ State=”local” Children=”force” />
           
    <Setting Id=”SETUP_REBOOT” Value=”Never” />
   
</Configuration>

 

This bypasses all prompts in the setup process and installs 12 proofing languages. I’m not going to list the languages here (OptionState Id values), as a table is available at: http://technet.microsoft.com/en-us/library/cc179219(v=office.15).aspx . That’s it for the configuration – now ready for deployment.

Source: http://technet.microsoft.com/en-us/library/ee942200(v=office.15).aspx plus all the forgotten ones…

 

Deploying Office Proofing Tools 2013 SP1

Internet is full of articles about deploying Office, but not so much about deploying the Proofing tools iso/CD. Most of the guides about deploying Proofing Tools with SCCM were about installing a specific proofing tool language, which you had to download separately. This method is fully working, but wasn’t what I was looking for. I got some ideas from http://www.scconfigmgr.com/2013/10/31/deploying-proofing-tools-for-office-2013-with-configmgr-2012/ for example, but this one was also only installing one language. The solution was to deploy using the custom.xml from above. Steps:

In SCCM:

  • New Application, fill in the details according to your needs.
  • Deployment Type: MSI (so you get the MSI product code). This will be changed. Select the MSI from \\yoursccmserver\Software\Office_2013_Proofing_Tools_with_Service_Pack_1\proofkit.ww and finish the deployment type guide.
  • The MSI-file itself can’t deploy custom stuff so we need to change the installation to use our custom.xml (Fig 1)

          proof_tools_sccm_1

          Fig 1. Remove the “\proofkit.ww” directory from the content location path.

  • Edit “programs” tab. The installation command should now include our custom.xml instead of the MSI-command. The command I used was: setup.exe /config \\sccm2012r2\Software\Office_2013_Proofing_Tools_with_Service_Pack_1\proofkit.ww\config.xml (Fig 2).

          proof_tools_sccm_2

          Fig 2. Programs/Installation program

  • I also use a dependency so that Proofing Tools can’t/won’t be installed if Office isn’t detected. On the Dependencies tab, select “Add”. Call the group whatever you want and add Office 2013 SP1 as a dependency (Fig 3).

          proof_tools_sccm_3

          Fig 3. Application Dependency.

  • I choose not to “auto install” Office with the proofing tools (Fig 4), as we sometimes just need to install proofing tools without office.

         proof_tools_sccm_4

         Fig 4. More Dependency-properties.

  • The rest of the information should be fine. I use install for system, whether or not a user is logged on, hidden.

 

Source: https://social.technet.microsoft.com/Forums/office/en-US/45ed8688-e7e4-415f-b26d-d3ae7bd9bc83/instaling-the-proofing-tools-kit-via-sccm

 

As a final note, do NOT use spaces in the directory name of proofing tools on the SCCM server. The custom.xml file will NOT be read correctly. I learned this the hard way after reading many office setup logs. (The logs are located in c:\windows\temp on the client during/after installation btw). I used the directory name “Office_2013_Proofing_Tools_with_Service_Pack_1” on our SCCM server.

Happy deploying! 🙂

Arduino and Rodin Deployment in SCCM 2012

I’ve been mostly focusing on MDT and other stuff so I haven’t posted that much about SCCM. Now it’s time to change that! 🙂 I’ll describe how I installed (and updated) Rodin and Arduino in our computer classroom. These aren’t perhaps the applications everyone use, but as we are an IT Department many “special cases” will arrive in our/my direction. Anyways, on to the installation. (This is btw not very well documented anywhere on Google 🙂 ) I may also add that the screenshots are from a virtual environment, NOT from our production server. Always test your stuff before breaking the production environment, OK?

I started by creating three applications (Fig 1), two for Rodin and one for Arduino. With Rodin I did a test-upgrade using supersedence (therefore two applications). With Arduino I just did an installation (the silent uninstallation does not work properly). There are probably many ways of doing this, and I’m not saying I’m doing it the “right” way. That said, it’s working.

sccm_applications

Fig 1. Arduino and Rodin Applications

 

Arduino

Deployment Type is the interesting part.

  • Create an application and manually specify the application information.
    • Name and manufacturer etc. etc. according to your needs.
    • Deployment Type: Script installer. Here are some parameters from the script installer:

arduino_content

Fig 2. Content

arduino_programs

Fig 3. Programs.

I googled and couldn’t find a silent installation switch for Arduino. I then googled some more and found a very useful little program called Universal Silent Switch Finder, http://www.portablefreeware.com/?id=2520. This helped me find the silent installation switch for Arduino (which was simply /S). I also did some research about the uninstallation switch, but came to the conclusion that it can’t be properly silently uninstalled even though I found the switch for it (also /S). This has to do with the installer itself, which in this case is Nullsoft Scriptable Install System (NSIS). Not going into any details here, just trust me. Anyways, not a big problem as this software isn’t going to be updated in our computer classroom anyway…

arduino_detection rule

Fig 4. Detection Method/Rule

arduino_user_experience

Fig 5. User experience

With these settings in place, you can successfully start deploying your application. I will not go through the application deployment process as it’s covered everywhere on the Internet. Only thing I can mention is that I use Action: Install and Purpose: Required. I won’t display the application in Software Center either.

 

Rodin

Deployment Type and Supersedence are the interesting parts. Rodin 1.2 and Rodin 1.3 are created basically in the same way, except 1.3 uses Supersedence.

  • Create an application and manually specify the application information.
    • Name and manufacturer etc. etc. according to your needs.
    • Deployment Type: Script installer. Here are some parameters from the script installer:

rodin_content

Fig 5. Content.

rodin_programs

Fig 6. Programs.

I have two subdirectories inside the main “rodin” directory; rodin_1.2 and rodin_1.3 (Fig 7). The directory also contain custom bat-files which “installs” and “uninstalls” Rodin. There are no installers or uninstallers available for Rodin (or Eclipse for that matter), Rodin is just an extracted zip file. The install bat-file copies the whole directory to a desired location and the uninstall bat-file on the other hand removes the directory. The bat-file also creates a shortcut on the Desktop for all users.

rodin_dir_screenshot

Fig 7. Custom bat files.

Contents of the install_rodin12.bat (same for 1.3 except dir name changes):

::Rodin Install Script

PUSHD %~dp0

xcopy “%~dp0rodin_1.2\*.*” “%PROGRAMFILES%\rodin_1.2\*.*” /I /Y /S & copy “%~dp0rodin_1.2\Rodin.lnk” “C:\Users\Public\Desktop”

POPD

exit /b 0

::Installation Complete

Source: http://www.experts-exchange.com/Programming/Languages/Scripting/Shell/Batch/Q_28187518.html

 

Contents of the uninstall_rodin12.bat (same for 1.3 except dir name changes):

rmdir /s /q “%PROGRAMFILES%\rodin_1.2” & del “C:\Users\Public\Desktop\Rodin.lnk”

Source: http://www.techsupportforum.com/forums/f10/batch-file-to-delete-folder-227649.html

 

The uninstallation information provided in Rodin 1.2 is then used before installing a newer version (1.3).

 

Next step is Detection Method:

rodin_detection_rule

Fig 8. Detection Method

For User Experience I will again choose to install for system, whether or not a user is logged on and visibility: hidden. That’s it for Rodin 1.2. The more interesting part is Rodin 1.3. The same steps are used as for 1.2, except Supersedence is defined. See Fig 9. The bat files defined for installation and uninstallation also has to match this current version.

rodin_supersedence

Fig 9. Supersedence.

 

Supersedence basically replaces the old application with the new one, using the uninstall information provided from the old application and the install information from the new application. And yes, it actually works. Old rodin_1.2 directory is removed and replaced by a new rodin_1.3 one.

Updating / Maintaining our Windows image

I just realised that I’ve never written about “regular maintenance” on our Windows 7/8.1 images. That said, I’ll try to write a short recap about the process. This procedure can be done in many different ways, but I’ll present my way of doing it. I’ll also write about an alternative (easier) method using sysprep and capture via MDT. Steps:

  • Started VMware and powered up a virtual machine with the old out-dated image. You should always use a virtual machine when making a golden image so you won’t end up with unnecessary drivers etc. in the image. Drivers will instead be added via MDT during deployment.
  • Ran Windows update. Updated everything.
  • Updated other software such as Firefox, Chrome, Skype and so on. My image-type is “fat”, so most of the programs are already in the image and won’t be added during deployment. This is a matter of taste though.
  • Didn’t change any local policies as they were up2date. This would be the time to change them if needed (using gpedit.msc)
  • Didn’t join the domain because none of the settings/changes needed domain membership. (The computer should NOT be domain joined when sysprepping either).
  • Took a snapshot in VMware before sysprepping. This step is important as you can repeat the steps above whenever you feel like making a new updated image. (You can only sysprep an already sysprepped image three times so snapshotting is your friend).
  • Ran sysprep from an administrative command prompt (Fig 1). If you’re interested in all the sysprep command line options, have a look at: http://technet.microsoft.com/en-us/library/cc721973%28v=ws.10%29.aspx. My command: sysprep.exe /generalize /oobe /shutdown /unattend:myfile.xml. There’s some stuff in myfile.xml that is specific to our University, but I won’t go into those details here. We sometime deploy computers manually (without MDT), so an unattend-file is needed. If you are interested in making your own unattend-file, look at http://technet.microsoft.com/en-us/library/cc748874%28v=ws.10%29.aspx or http://emeneye.wordpress.com/2012/02/23/building-an-unattended-answer-file-for-windows-7-2/ for examples.

          sysprep

          Fig 1. Sysprep

  • After this step the virtual machine is in a shutdown state. I will power on the virtual machine again, but this time choose to boot from the network (Fig 2; Windows Boot Manager has been loaded from the WDS server). The vm is connected to the same physical network as the WDS/MDT server.

          windows_boot_manager

          Fig 2. Windows Boot Manager.

          mount_deploymentshare_from_winpe

          Fig 3. Mounting the Deployment share from WinPE.

  • After the Deployment share is mounted, the next step is to capture the current image onto the share. The following command was used: imagex.exe /compress maximum /capture d:\ z:\win7image.wim “Image 29.8.2014” (Fig 4). The drive letters often gets mixed up in WinPE, so be sure to check that you are capturing the correct drive. In my case “the usual c:\” was mapped as d:\ , and therefore I’,m using the /capture d:\ -command above.

          capture_image_from_winpe

          Fig 4. Capturing the image. It’ll take  a while…

  • After a while you’ll have a captured image that you can add to your MDT-server (or just deploy manually with a WinPE Boot CD for example).
  • That’s it. Just add/import the newly created image to MDT (Fig 5, Fig 6) and remember to update the Task Sequence to use the newly created image (Fig 7).

          import_os_mdt

          Fig 5. Adding the image to MDT.

          import_os_mdt_importing

          Fig 6. Importing… it’ll take a while.

          check_os_in_mdt

          Fig 7. Updating the Task Sequence to use the new image

  • You can now revert your snapshot in VMware and do the above steps over and over again 🙂 (I reverted before I wrote the following chapter about the alternative method for example).
  • Deploy!

 

Alternative method:

With this method you’ll capture an image from an updated, “ready to be imaged” virtual machine with the following steps:

  • Start MDT and create a new Task Sequence. Select “Sysprep and Capture”. Fill in the fields with the needed information. Most of this information is already pre-stored in the image/vm that will be sysprepped and captured, but you’ll have to at least fill in Name and Organization. The product key will be taken from KMS, so no need to specify that in my case. The admin password can be specified or non-specified according to taste. However, when you deploy the image it  will still have a disabled administrator account. (A script renames and disables the admin account during deployment in my case).
  • Verify/Edit the MDT rules. SkipCapture should be set to NO (Fig 8). I also set SkipDeploymentType=NO so that the wizard will ask me to capture an image (and also ask what to do with it). This setting was changed after the screenshot though.

           Skipcapture_no

           Fig 8. SkipCapture=NO

  • Move away from MDT and head back to your client.
  • Instead of manually entering the sysprep.exe –command, mount the MDT network share (\\WDSSERVER\DeploymentShare$) from your running non-domain joined virtual machine. After mounting the MDT share, navigate to the Scripts -directory and run “LiteTouch.vbs” (Fig 9).

           LiteTouch_vbs_from_win7

           Fig 9. Mounting Scripts folder and running LiteTouch.vbs

  • Choose the Sysprep and Capture Task Sequence that you created earlier (Fig 10).

           sysprepandcapture_ts

           Fig 10. Sysprep and Capture Task Sequence

  • Specify that you want to Capture an image of this reference computer (Fig 11). The default “Captures”-location is fine. Click next.

           sysprep_and_capture_location

           Fig 11. Capture an image of this reference computer

  • Sysprep starts and does its magic (Fig 12). After this the computer automatically restarts into WinPE and captures the image (Fig 13).

           sysprep_is_working_plz_wait

           Fig 12. Sysprepping

           create_wim_capturing

           Fig 13. Capturing the image (wim).

 

That’s it! Image is now captured and you are ready to deploy it.

You’ve now witnessed image making/capturing in two different ways. Even though Deployment is something I often work with, I can’t remember everything. I refreshed my memory with a little bit of help from http://www.vkernel.ro/blog/sysprep-and-capture-a-windows-image-with-mdt-2012.

As usual, if you are interested in the whole deployment process, read my earlier (popular) post Deploying Windows 7/8 with Microsoft Deployment Toolkit (MDT) 2012 Update 1 and Windows Deployment Services (WDS).

Migrating MDT 2013 from Windows Server 2008 R2 to Windows Server 2012 R2

Our Deployment Server (Windows Server 2008 R2) was getting a bit dated and I wanted to enjoy all the new WDS-features of Windows Server 2012 R2 (better UEFI support and enhanced boot image download performance for example). In this migration case I’ll be using physical servers so the migration will be physical-to-physical. The servers are old but they have enough power for the job 🙂

Old server (Fig 1):

  • Fujitsu Siemens Primergy RX300 S2
  • 2 x Intel Xeon 3.20GHz CPUs
  • 4GB RAM
  • 6 x 146GB SCSI HDDs in HW RAID-5

fusi_primergy

Fig 1. Fujitsu Siemens Primergy RX300 S2 (currently running Windows Server 2008 R2).

For the replacement/migration I originally had an identical server which ran Windows Server 2008 R2. It got upgraded to Windows Server 2012 some time ago however. I now tried upgrading it to Windows Server 2012 R2, but it just failed to start properly after the setup process was completed (error message and endless reboots). This was (probably) due to the same problem as before, as there are no drivers for the LSI MegaRAID 320-2E card. It was possible to trick the Windows Server 2008 R2 installation to use the Windows Server 2003 drivers (newest ones available), but this wasn’t the case with a clean install of Windows Server 2012 (R2). However, an upgrade from 2008 to 2012 was/is possible. As a server 2012 to server 2012 R2 upgrade wasn’t possible due to errors, I thought I’d try with the old method. That said, I clean-installed Server 2008 R2, and tried a Server 2012 R2 upgrade instead of the Server 2012 upgrade. This upgrade path wasn’t “allowed” by MS however, so I HAD to do a clean install. Well, I ran into the exact same problems as with the Server 2012 to Server 2012 R2 upgrade. The server won’t start properly, due to a very old and unsupported LSI MegaRAID card. Anyways, it was time to move on as I won’t waste any more time on these old bastards (Fujitsus).

This was not the end of the world though, I just used an old workstation instead of a server. It doesn’t have to be a hard-core server anyhow, because we usually don’t have many simultaneous deployments. It’s basically enough having a normal workstation with decent capacity hard drives in a raid configuration for safety (raid-1 or 5). Normally this sort of thing would be a good candidate for a virtual machine also, but our hosts are a bit full at the moment so it would’ve been even slower 🙂 With that said, here’s the “new server” (Fig 2):

  • Osborne (in an Antec Sonata III case) with Asus PQ5-EM motherboard
  • Intel Core 2 Duo 3.16GHz CPU
  • 4GB RAM
  • 2 x 250GB HDDs in HW RAID-1

sonataIII

Fig 2. “Osborne”

I installed the new “server” from scratch and copied over the needed content from the old server as the progress continued. Steps:

  • Installed Windows Server 2012 R2 from DVD
  • Ran Windows Update to get it fully patched
  • Installed Classic Shell (yes, I still don’t like Metro)
  • Installed Notepad++ for easier editing of configuration files
  • Installed Intel Rapid Storage Technology from Intel.com to monitor raid health (Fig 3). Also configured email alerts.

          intel_RST 

           Fig 3. Intel RST

  • Partitioned/Resized the hard drive: 60GB for the system drive and the rest for data (Deployment Share)
  • Downloaded and installed ADK 8.1 for Windows 8.1 Update
  • Downloaded and installed MDT 2013
  • Enabled WDS Server Role
  • Set a static IP
  • Joined the production domain
  • Copied the whole Deployment Share directory (about 60GB) from the old server to this new one, (D:\DeploymentShare)
  • Shared the new Deployment Share directory via file sharing
  • Started MDT 2013 and chose to Open Deployment Share. Pointed it to the newly copied directory, D:\DeploymentShare (Fig 4)

          open_deployment_share

          Fig 4. Open Deployment Share

  • Successful import! (Fig 5)

          open_deployment_share_success

          Fig 5. Open Deployment Share – success.

  • Went to properties on the Deployment Share and changed UNC path to point to the new server (Fig 6)

          set_depl_share_unc_path

          Fig 6. Set Network (UNC) path

  • Edited D:\DeploymentShare\Control\Bootstrap.ini and changed DeployRoot to point to the new server (Fig 7)

          unc_path_inbootstrap_ini

          Fig 7. DeployRoot in Bootstrap.ini

  • Updated the Deployment Share. MDT-part now done.
  • Started WDS and configured it (kind of self-explanatory so won’t add any steps or screenshots)
  • Added the newly created boot image from MDT (D:\DeploymentShare\Boot\LiteTouchPE_x86.wim) to WDS Boot Images
  • Changed the TFTP Maximum Block size for better boot image download performance (Fig 8). This is a new feature in WDS on Windows Server 2012 (R2). More information: http://technet.microsoft.com/en-us/magazine/dn163597.aspx. Yeah, it’s actually noticeably faster.

          wds_tftp_max_block_size

          Fig 8. TFTP Maximum Block Size

  • Updated the DHCP configuration on our Linux DHPC server to point to the new server
  • Ran a test-deployment – Everything worked as before, except now I’m using a newer version of WDS with better UEFI support 🙂
  • Success yet again!

 

Source: http://lacietech.blogspot.fi/2010/10/migrating-mdt-2010-from-one-server-to.html

As usual, if you are interested in the whole deployment process/configuration, read my earlier post: Deploying Windows 7/8 with Microsoft Deployment Toolkit (MDT) 2012 Update 1 and Windows Deployment Services (WDS)

Adding PXELINUX to WDS (Mixed-mode Windows/Linux Deployment)

I’ve been using WDS + MDT for a long time and I’ve been happy. This didn’t stop me from thinking about adding more PXE alternatives than the standard (Windows) WDS PXE environment though. I like to experiment, and this time I experimented with a mixed-mode of Windows and Linux PXE. What you’ll need in short is PXELINUX to replace your out-of-the box WDS pxe-boot environment. Your old familiar Windows Deployment Services will still be left intact, it will just be added as a separate PXE boot option in the boot menu. I found some pretty good instructions, but as usual I like to write my own. I won’t write about the whole experiment though, as the main guide is available from:

http://thommck.wordpress.com/2011/09/09/deep-dive-combining-windows-deployment-services-pxelinux-for-the-ultimate-network-boot/

I followed the guide, with the following changes:

  • Could not find all (three) files in any of the syslinux-packages I tried downloading from kernel.org. My solution was to (yum) install this package on one of my test-workstations and just copy the files from there. It happened to be a Fedora Core 19 if someone is interested.
  • Copied the files to \\RemoteInstall instead of \\Reminst (I’m using Windows Server 2008 R2, to be upgraded to 2012 R2 soon).
  • Copied the files to BOTH x64 and x86 directories on the WDS server. My virtual machine didn’t like booting from x86 even though my newly created virtual test machine was supposed to be 32 bit. Oh well, with the files copied for both architectures it did work. I did my changes in the x64 directory however.
  • Because of this, I also had to change the flag in the wdsutil command:
    • wdsutil /set-server /bootprogram:boot\x64\pxelinux.com /architecture:x64
    • wdsutil /set-server /N12bootprogram:boot\x64\pxelinux.com /architecture:x64
  • Added Gparted Live, Memtest86+ and (later) Ubuntu to the menu
  • Did a test-run and it booted 🙂 (Fig 1)

pxe_boot_menu

Fig 1. PXE Boot Menu (Pxelinux/Syslinux). Better screenshot later in the document (Fig 10).

memtest

Fig 2. Memtest86+

  • Configured GParted Live a bit different than in the guide. I had to scratch my head a bit for the fetch=http part but got it working (UPDATE: now using NFS instead, see note).
    • Didn’t quite understand the webserver part (and I’m not an expert on IIS). Had a look at http://www.syslinux.org/wiki/index.php/WDSLINUX which gave me some small hints… “If on IIS create a new virtual directory and set the mime type for .* extension to text/plain)”. Still very cryptic to me though 🙂
    • Well, doesn’t hurt to try. I installed the IIS Server Role on the WDS Server.
    • Went to properties and created a new virtual directory (Fig 3). The alias was set to “gparted” and the physical path to D:\RemoteInstall\Boot\x64\Linux\gparted (where all the files for gparted are stored).

iis

Fig 3. IIS Manager

  • Created the mime type for .* (Fig 4).

iis2

Fig 4. Setting mime type for .*

  • Also changed the configuration file in syslinux/pxelinux to point to this virtual directory:
    • append initrd=\Linux\gparted\initrd.img boot=live config  noswap noprompt  nosplash  fetch=http://x.x.x.x/gparted/filesystem.squashfs
    • Actually worked 🙂 (Fig 5)

gparted

Fig 5. GParted booted in an “empty” 5GB virtual machine with no partitions.

 

NOTE: Not using http/IIS for GParted anymore. Also got this working with NFS. Read the next chapter about Ubuntu and you’ll understand. I just copy/paste the working configuration here:

LABEL gparted
    MENU LABEL GParted Live
    kernel \Linux\gparted\vmlinuz
    append initrd=\Linux\gparted\initrd.img boot=live config noswap noprompt nosplash netboot=nfs nfsroot=x.x.x.x:/Linux/GParted
    # append initrd=\Linux\gparted\initrd.img boot=live config  noswap noprompt  nosplash  fetch=http://x.x.x.x/gparted/filesystem.squashfs (not in use now)

Other changes from http to NFS: I had to make a directory called “live” and copy/move the filesystem.squashfs into that dir. Source: http://gparted-forum.surf4.info/viewtopic.php?id=14165

 

Moving along to Ubuntu…

I found many guides, but they were all about the same. None with working configurations for me 😦 I had to try almost everything with trial and error. I’m still not even sure if the problem was a bad parameter or a wrongly configured NFS Server. Oh well, to help anyone else out there, here are my steps (in no particular order):

  • Got a headache from all the testing 🙂
  • Downloaded Ubuntu Netboot Image from http://cdimage.ubuntu.com/netboot/
  • Downloaded an Ubuntu ISO, 13.10 (64-bit) in my case
  • Extracted both the Netboot Image and the Ubuntu ISO and copied them to the WDS Server:
    • D:\RemoteInstall\Boot\x64\Linux\Ubuntu\ubuntu-installer (Netboot version)
    • D:\RemoteInstall\Boot\x64\Linux\Ubuntu\ubuntu-full (Extracted Full version ISO)
  • Add the Role Services: Services for Network File System to your WDS Server (Fig 6).

nfs_server2008r2

Fig 6. Services for Network File System (NFS)

  • Configured NFS. My steps in the screenshot (Fig 7):

nfs_sharing_steps

Fig 7. NFS-Sharing

  1. Manage NFS Sharing… (Choose Properties/NFS Sharing on the dir. I shared D:\RemoteInstall\Boot\x64\Linux)
  2. NFS Advanced Sharing (changed settings according to picture)
  3. Permissions (put a mark in Allow root access)

 

I got very confused with all the parameters from all the instructions found. I seems that the vmlinuz-file isn’t the same in Ubuntu 13.10 as in older distros. Correct me if I’m wrong. It took me a long time to figure out the correct settings for the configuration file “default” (\Boot\x64\pxelinux.cfg\default).

After some serious testing, it turned out that I had to use a combination of both the Netboot version and the full version of Ubuntu to get my Live-CD to PXE boot.

Here’s a sample from http://www.howtogeek.com/61263/how-to-network-boot-pxe-the-ubuntu-livecd/ which didn’t work out of the box for me:

LABEL Ubuntu Livecd 11.04
MENU DEFAULT
KERNEL howtogeek/linux/ubuntu/11.04/casper/vmlinuz
APPEND root=/dev/nfs boot=casper netboot=nfs nfsroot=<YOUR-SERVER-IP>:/tftpboot/howtogeek/linux/ubuntu/11.04 initrd=howtogeek/linux/ubuntu/11.04/casper/initrd.lz quiet splash --

In this example, the Ubuntu files are extracted to \Linux\Ubuntu\11.04. On my server that would correspond to the exact path of D:\RemoteInstall\Boot\x64\Linux\Ubuntu\11.04. Then there are a bunch of sub-directories, one of which is namned “casper”. Casper holds the kernel so Ubuntu can start/boot over network/pxe. HOWEVER, on Ubuntu 13.10, there’s NO file called vmlinuz, it’s called vmlinuz.efi. Afaik, pxelinux can’t boot this file (at least not on my test setup. Don’t know about the EFI-support on pxelinux either…). Well, the solution was to use the netboot version for the kernel and the full distro (extracted) for the actual installation. It’s probably easiest to just post my current working configuration:

LABEL Ubuntu
    menu label Ubuntu 13.10, 64bit
    kernel \linux\ubuntu\ubuntu-installer\amd64\linux
    append root=/dev/nfs boot=casper netboot=nfs nfsroot=x.x.x.x:/Linux/Ubuntu/ubuntu-full initrd=/Linux/Ubuntu/ubuntu-full/casper/initrd.lz quiet splash

I have extracted the Ubuntu netboot version to D:\RemoteInstall\Boot\x64\Linux\Ubuntu\ubuntu-installer and the full version Ubuntu to D:\RemoteInstall\Boot\x64\Linux\Ubuntu\ubuntu-full. I’m sharing the “Linux” dir over NFS as described earlier.

All of this configuration was just for a plain installation of Ubuntu 13.10. There’s much that can/should be automated with kickstart or similar. There are some packages that should be installed in the post-phase of the installation and also some configuration files that should be copied (from the nfs share). I’ll leave this for another post.

 Ubuntu_install1

Fig 8. Ubuntu pxe-booted “live”.

Ubuntu_install2

Fig 9. Installing Ubuntu from the live session

 

My configuration file if someone is interested:

DEFAULT      vesamenu.c32
PROMPT       0

MENU TITLE Abo Akademi, Dept. of IT PXE Boot Menu
MENU INCLUDE pxelinux.cfg/graphics.conf
MENU AUTOBOOT Starting Windows Deployment Services in 8 seconds…
         
# Option 1 – Run WDS
LABEL wds
          MENU LABEL Windows Deployment Services
         menu default
         timeout 80
         TOTALTIMEOUT 9000
          KERNEL pxeboot.0

        
# Option 2 – Run gparted
LABEL gparted
    MENU LABEL GParted Live
    kernel \Linux\gparted\vmlinuz
    append initrd=\Linux\gparted\initrd.img boot=live config noswap noprompt nosplash netboot=nfs nfsroot=x.x.x.x:/Linux/GParted
    # append initrd=\Linux\gparted\initrd.img boot=live config  noswap noprompt  nosplash  fetch=http://x.x.x.x/gparted/filesystem.squashfs (not in use anymore)
   

# Option 3 – Run memtest86+
LABEL memtest86+
    menu label Memtest86+
    kernel \Linux\memtest\memtest

   
# Option 4 – Ubuntu
LABEL Ubuntu
    menu label Ubuntu 13.10, 64bit
    kernel \linux\ubuntu\ubuntu-installer\amd64\linux
    append root=/dev/nfs boot=casper netboot=nfs nfsroot=x.x.x.x:/Linux/Ubuntu/ubuntu-full initrd=/Linux/Ubuntu/ubuntu-full/casper/initrd.lz quiet splash

   
# Option 5 – Exit PXE Linux
LABEL Abort
         MENU LABEL Exit
         KERNEL abortpxe.0

 

I left graphics.conf with its default settings (Fig 10, modified in Fig 1). Here is a screenshot of the whole thing in action:

pxe_boot_menu_final

Fig 10. PXELinux PXE Boot Menu

I already have screenshots from the other alternatives on the boot menu, so just for fun I added some screenshots when I’ve pressed the default option to boot Windows Deployment Services:

wds_loading_files_pxelinux1

Fig 11. Loading boot file from WDS.

pxelinux_wds_mdt_task_sequences

Fig 12. After the boot file has loaded from WDS, it’s time for MDT’s Task Sequences. Everything about this procedure is already covered in my previous post Deploying Windows 7/8 with Microsoft Deployment Toolkit (MDT) 2012 Update 1 and Windows Deployment Services (WDS)

 

Are you still reading? Instead go ahead and try PXE booting every OS out there 😉

 

Sources (those that I can remember):

http://www.syslinux.org/wiki/index.php/WDSLINUX
http://www.howtogeek.com/61263/how-to-network-boot-pxe-the-ubuntu-livecd/
http://s205blog.wordpress.com/2012/10/02/ubuntu-12-04-lte-pxe-network-installation-tutorial/
http://rebholz.wordpress.com/2012/05/17/technical-how-to-installing-linux-edubuntu-using-pxe-boot-and-windows-7-as-a-server/
http://www.howtogeek.com/162809/how-to-pxe-boot-an-ubuntu-image-from-windows-server-2008/