Importing AD powershell module into Windows PE and then using encrypted creds

Powershell makes life much easier than vbscript…. however it does have its downsides…  signing policy can sometimes be a bit of pain and the modules you need have to be available…. which is an issue in particular for Windows PE.

Mick (good aussie name there) was nice enough to write a blog on how to import powershell into PE – without having to add it statically to the boot wim – http://mickitblog.blogspot.com.au/2016/04/import-active-directory-module-into.html

I was a little lazy here and copied both x86 and x64 required directories via robocopy rather than determining the version via powershell like Mick did.

The next step however is the more important one…. a task sequence doesn’t allow us to run a powershell command in PE with credentials, we need a secure way of running the command. In my case, I want to delete a computer object….

Step 1 – Generate a key file (perform on any full OS)

$KeyFile = “\\sccm\PSource$\OSD.DeleteComputer\DeleteComputer.key

$Key = New-Object Byte[] 16

[Security.Cryptography.RNGCryptoServiceProvider]::Create().GetBytes($Key)

$Key | out-file $KeyFile

 

Step 2 – Encrypt a password using the key

$PasswordFile = “\\sccm\PSource$\OSD.DeleteComputer\DeleteComputer.txt

$KeyFile = “\\sccm\PSource$\OSD.DeleteComputer\\DeleteComputer.key

$Key = Get-Content $KeyFile

$Password = “Your password here” | ConvertTo-SecureString -AsPlainText -Force

$Password | ConvertFrom-SecureString -key $Key | Out-File $PasswordFile

 

Step 3 – Create your script utilising the creds – (Below is the one I use to delete a computer object)

Import-module ActiveDirectory

#SCCM TS Object
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment

#SCCM Variables
$CompName = $tsenv.Value(“_SMSTSMachineName”)

# Get current path in order to get encrypted password
$MyDir = [System.IO.Path]::GetDirectoryName($myInvocation.MyCommand.Definition)
$User = “Domain\Account”
$PasswordFile = “$MyDir\DeleteComputer.txt”
$KeyFile = “$MyDir\DeleteComputer.key”
$key = Get-Content $KeyFile
$MyCredential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, (Get-Content $PasswordFile | ConvertTo-SecureString -Key $key)

# Remove the computer from AD
Remove-ADComputer -Identity $CompName -server <DC name required> -Credential $MyCredential -confirm:$false

 

Now before you say it…. yes, this is not very secure. It will stop a random snooper type person from seeing a plain text password…. but it will not stop someone who has 1/2 an idea about pressing F8 to get into the running TS (if you have it enabled) and then grabbing the key and txt and being able to use them…. so use (or don’t use) appropriately for your environment.

UEV now included in Windows 10 1607 (and above)

User Experience Virtualization (UEV) use to be part of the MDOP packs…. however MDOP’s last update was in 2015…. leaving some of us wondering what was happening to awesome tools contained within.

Given Microsoft’s recent desire to destroy anything and everything that isn’t cloud – irrelevant of its ability to fill gaps that cloud services don’t currently service well, or their ability to facilitate migration to cloud – it seemed likely that these tools were dead.

Fortunately for UEV, its now included in Windows 10 Enterprise as a default service, for versions 1607 and 1703 (and we may be able to assume future releases as well). Some details on the release are here – https://docs.microsoft.com/en-us/windows/configuration/ue-v/uev-whats-new-in-uev-for-windows

Unfortunately, in standard Microsoft fashion, the documentation is not good.

The UEV documentation is located here – https://docs.microsoft.com/en-us/microsoft-desktop-optimization-pack/uev-v2/deploy-required-features-for-ue-v-2x-new-uevv2

However, there are a few, quite important things that anyone deploying this should be aware of

  • Even though it isn’t stated anywhere in the doco, and seems quite counter-intuitive based on what’s presented in the GPO settings, the default Microsoft included templates do not automatically register on clients. These can be copied to your custom templates path, or you can register them with powershell on each machine as per http://ccmexec.com/2017/02/synchronizing-ie-favorites-with-ue-v-in-windows-1607/
  • The UEV template generator is part of the ADK (1607 or 1703) – however, it does not show up if you try and run the ADK installer on Windows 8.1 or server 2012 R2. I haven’t tried on Windows 10 versions below 1607 or 1703 – but it will show/be installable on those versions.

Upgrading Hyper-V integration components via SCCM

Keeping Hyper-V integration components up to date on all your hyper-V guests has a few options, Powershell and SCO being the common ones…. but im one of these whacky people that likes to keep deployment tasks within my deployment tool – SCCM.

Unfortunately, the integration services version doesn’t seem to be exposed via properties exposed by default to SCCM, such as hardware inventory (which includes add/remove programs).

Due to this, we have to use software inventory.

To this end, I enable software inventory for C:\Windows\System32\drivers\vmbus.sys

The version of this, once reported, isn’t quite clean. Instead of 6.3.9600.18398, we get “6.3.9600.18398 (winblue_ltsb.160625-0600)”, so this is what needs to be used in your collection queries in order to have anything show up in your collections.

SCCM 2012+ – Bug when building query using values selector for Software files – File modified date

This is a fairly uncommon thing…. but, its still there.

When using SCCM, sometimes its necessary to use software inventory and the “Software Files” class – to determine the versions of software that is in your environment.

Normally, we would use Software Files – File Name and Software Files – File Version and that would be enough.

We have one client, who has some software developed by a particularly shitty vendor, who releases different software versions with the same version number, so we needed to look for the exe, the version, but also the Software Files – File Modified Date.

When selecting the file modified date, like most reasonable people, you would select the “values” button and select the correct entry – or based your entry on that format… unfortunately, in this case, the entry values shown in the below dialogue box, are not the same as the ones in the database.

The values box in SCCM

Bug.1

The view data in SQL

Bug.2

Notice the different values

 

If I select a value, or use the format from the values box, I get a collection with 0 members, as nothing matches that criteria

Bug.3

If, however, I enter the value in the correct format from the database, we are all good

Bug.4

 

Anyhoo – I realise this is an unusual situation…. most developers realise that incrementing version numbers is a good thing. Still, there’s an small chance this might help someone out there.

ADK 1511 – don’t use it quite yet

http://blogs.technet.com/b/configmgrteam/archive/2015/11/20/issue-with-the-windows-adk-for-windows-10-version-1511.aspx

Pretty minor… its not as if many people that use SCCM would use the ADK…. only 100% of them.

Some interesting comments at the bottom of the page…

Previously I was one of those who thought Microsoft’s patching and release quality testing was getting better… and it was… for a while… but between this, the MDT 2013 U1 buggy release, multiple exchange RU’s that got released and re-released, the windows update that killed outlook… well, I think MS might have some QA issues.

Java 8 update 60 install with SCCM

Java….. not only is the product itself pretty much a virus, the deployment and ongoing management of it just plain sucks.

 

It seems that for Java 8 update 60, the dev’s have managed to add that little bit more complexity.

If you download and install the offline installer from the java web site (http://www.java.com/en/download/manual.jsp), you get the familiar .exe with an msi within it.

The msi can be obtained by simply running the installer and navigating to C:\users\%username%\AppData\LocalLow\Oracle\Java\jre1.8.0_60 <or similar for later versions>

This has been a common method of getting the MSI then simply putting it into SCCM for years…. but now there is a requirement to have the file C:\Programdata\Oracle\Java\Java.Settings.cfg in place before running the MSI.

 

So… what about alternate methods

Using the recommend approach by Oracle – http://www.oracle.com/technetwork/java/javase/silent-136552.html results in utilising the executable with a config file.

From my testing, it seems that the config file must be fully path’ed and must be on a local drive (i.e. not a unc path) – this is do-able via SCCM by simply scripting the files to be copied locally and executed….  but this is turning something that should be simple into more lines than it needs to be. You can still use the msi detection method – but having the msi already extracted makes finding the code just quicker and easier.

Another method is to get the java natively as an MSI as per https://www.java.com/en/download/help/msi_install.xml , however, this required an oracle logon – and even with the logon, unless you have ” Oracle Java SE Advanced” (whatever that is), you do not get access to it.

 

Why is this so fucked?

I’m going to go out on a very very short limb here and suggest that Java is almost universally hated by deployment admins, its not that its stupidly hard – its that the deployment methods seem to change regularly, they do stupid things such as make a compiling a jar file required for updating security settings (java 7 update 51) and just generally seem to love making deployment and management of Java far far harder than it needs to be… for reasons best known to themselves.

In this instance, its not obvious from the doco (nor past experience) that this file needs to be copied down first.

When it does become clear, thanks to posts such as https://www.reddit.com/r/SCCM/comments/3iq6tq/installing_java_8u60_during_bc_task_sequence/?

all it does is add another un-necessary step to the packaging process….  and kill time.

 

Anyhoo – in short, to sum up

Extract the msi (as you have for the last few years) from the java install exe

Create your app

Copy a pre-made java.settings.cfg to C:\Programdata\Oracle\Java\Java.Settings.cfg (settings can be found here http://docs.oracle.com/javase/8/docs/technotes/guides/install/config.html#installing_with_config_file )

Install your MSI

Shake your head and wonder why they don’t just give us an msi in the first place