I’ve just finished a mission for a client that didn’t want to have its workstations remastered in order to join the domain, they wanted to go with the new ‘Masterless’ trend based on Windows ICD…

So, here is my feedback on this new experience, which I confess was not that smooth, and rather disappointing. It’s ICD’s first version and there is no deep dive documentation available right now… all demos, all examples are over simplified and show only two available features: An ‘On-premise’ domain join or the now classical: ‘I’ll change Windows Edition to Enterprise using ICD’. Otherwise, nothing… so virtually nothing useful!

My client’s requests where rather common:

· Install applications

· Join Domain (Azure AD + Intune)

· Block Cortana and Telemetry, etc.

But problems raised as we started using it: what’s the difficulty of installing applications to workstations? It’s quite simple right? Well, you’ll see it’s all on the ‘it depends’ base.

Join domain: easy! With Azure AD/Intune… ‘It depends’.

Regarding Cortana/ Telemetry and others, everything rolls out fine – if you have an Enterprise version- otherwise, it’s less fun!

The whole point of these next 3 posts is to provide an overview on ICD while we wait for its next version that will surely be available soon with the Anniversary Update and the new Windows 10 LTSB on the 2nd of August. My advice at the moment is: WAIT!

In the meantime, let me tell you the first problem I faced: Installing applications (classic Win32 apps)

· Only one type of ‘execution’ command can be integrated

· You cannot select a FOLDER as a source, only single FILES.

· Installation is controlled by a script the ‘old school’ way, if you need logs you’re going to have to produce them.

· As application files are not each one in their own FOLDER, you’ll have to be careful when naming them: you cannot have 3 setup.exe in the same location!

You see it’s not as simple as it seems, and we are not here to complain about the difficulties but to bring out the solutions to the problems!

Step one: a single execution command… and it looks like this:

Meaning we have to create an orchestrator script that controls each and every software installation:

If we follow the online help available in the ICD console we get directed to a KB on TechNet explaining how to do these scripts (so far, nothing new) and it goes like this:

echo Installing 7zip >> %LOGFILE%

7zip_x64.exe /S >> %LOGFILE%

echo result: %ERRORLEVEL% >> %LOGFILE%

set LOGFILE=%SystemDrive%\Java_install.log

echo Installing Java >> %LOGFILE%

msiexec /i Java1.8.0_66.msi /quiet >> %LOGFILE%

echo result: %ERRORLEVEL% >> %LOGFILE%

set LOGFILE=%SystemDrive%\AcrobatReaderDC_install.log

echo Installing AcrobatReaderDC >> %LOGFILE%

msiexec /i AcroRead.msi /q >> %LOGFILE%

echo result: %ERRORLEVEL% >> %LOGFILE%

set LOGFILE=%SystemDrive%\Office_install.log

echo Installing Office2016ProPlus >> %LOGFILE%

setup.exe /S >> %LOGFILE%

echo result: %ERRORLEVEL% >> %LOGFILE%

Rather simple until now… kind of ‘OLD SCHOOL’ but not complicated.

Here comes the funny part: no problems with 7Zip or Java… but when it comes to Acrobat Reader…

It gets annoying… I need to access the sources and launch a classical msiexec… BUT! In the sources I have a SETUP.EXE that will not allow me to use Office2016ProPlus’s own SETUP.EXE. Yet, my files have no specific tree structure in ICD and this is when it gets hot! With MDT/SCCM I’d take the Acrobat folder, and launch the usual MSIEXEC command. Yet, Acrobat has in its own sources a setup.exe, as does Office and many more applications. So, when we ‘feed’ the application sources to ICD, since we cannot select Folders but only individual Files, we’ll get stuck when trying to import the second setup.exe, or any other file with a duplicate name.

Never mind, I’ll go with method 2 for Acrobat, and skip that issue so I can go on with Office 2013… -Since client is on my back-

What is Method 2? Well: we get back to the downloaded .exe file from Adobe’s site without even extracting it. We’ll just run it with the silent install switches as shown in the section below, so we have only one file to import in ICD for Acrobat, as for Java and 7Zip… easy, right?

set LOGFILE=%SystemDrive%\AdobeDC_install.log

echo Installing AdobeDC >> %LOGFILE%

AcroRdrDC1501620039_fr_FR.exe /sAll /rs >> %LOGFILE%

echo result: %ERRORLEVEL% >> %LOGFILE%

Back to Office… Usually you create an answer file using setup.exe /admin, drop it in the updates folder in Office’s sources and launch setup.exe to install it.

But not in this case, remember: No Folders in ICD!

This is when you wish you were somewhere else… You begin to look for a solution thinking you cannot be the first geek in the world trying to figure out how to push Office with ICD…Come on!!!

Turned out, apparently I’m not the first I’m the second one! After a long search -both on Bing and Google- I found a nice blog post written by, Samir Hammoudi from Microsoft Japan who I Thank for his help and support. He’s the only one to my knowledge to have pushed ICD a little further than the usual Microsoft demo! A big thanks again, to save us from spending a lot of time figuring it out.

His idea is simple yet efficient, you just ZIP the Office folder and then create a PowerShell script to unzip it and install it. That was it, Samir did it and shared it, so it’s my turn to pass it on!

Read his article, get the script, will use it in the second part. Thanks to Samir we’ve been able to use his script and method to install a lot of complex applications. This script is now a part of my tool-box until Microsoft fixes the folder issue feature, in ICD.

We ended up with a o365.ZIP and a PowerShell installation script, so our orchestration script looks like this: