Microsoft – CB-Net

OSD Wizard Updates (0.95 release)

Chris Bradford — Sun, 17 Sep 2017 14:12:49 +0000

I’ve worked my way through a series of additional features for OSD Wizard (a ConfigMgr/ SCCM Task Sequence front-end/ modern HTA) this week – namely the introduction of run-time “modes” – Default, Set-Description, ExportOU, Test. With these modes you can now:

Set AD Computer Account description mid-Task Sequence using OSD Wizard/ Web Service as opposed to using a separate script with RunAs credentials
Perform a compatible OU export using the OSD Wizard script itself (and automate/ schedule this if so desired), rather than performing this manually
Fully test OSD Wizard outside of a Task Sequence environment (without the need for the SMS TS Environment COM Object) – including the ability to spoof platform information/ properties.

Grab a copy of the latest release here: https://gitlab.com/chrismbradford/osd-wizard

Introducing OSD Wizard – A PowerShell Front-End / HTA for ConfigMgr Task Sequences

Chris Bradford — Mon, 04 Sep 2017 21:48:07 +0000

When I first started working with SCCM/ ConfigMgr a few years ago I ran into several issues with upstream teams trying to deploy Task Sequences to devices that were untested (i.e. there were no drivers), power was not plugged in, the user supplied hostname was duplicated in target domain etc. This generated unnecessary Incidents, and delays in getting devices out to users. I became increasingly frustrated at the lack of ConfigMgr built-in capabilities to address these issues, so I turned to vbScript to write a HTA / front-end to address these issues. vbScript is now, several years later, a dying technology, so over time I have re-written the vbScript/ HTA in PowerShell, leveraging WPF and XAML to generate a user interface.

OSD Wizard is a PowerShell script with a WPF/ XAML-based UI built for use within System Center Configuration Manager (SCCM / ConfigMgr) Task Sequences – it has two key purposes, the second of which is optional:

Reduce “human error” factors during early stages of Operating System Deployment
Enable location (network) derived automation for multi-language environments

You can read through the details of the project, download and review the source code (and even contribute!) via GitLab, here: https://gitlab.com/chrismbradford/osd-wizard

ConfigMgr Windows 10 Enterprise 1703 Stuck at “Just a moment”

Chris Bradford — Fri, 18 Aug 2017 22:47:08 +0000

I ran into an issue when testing Windows 10 Enterprise 1703 in the lab, when deploying via ConfigMgr Current Branch – essentially after image deployment the machine would reboot and just show a blue screen with “just a moment.”

I came across this post which led to the solution – a modification to the Unattend.xml:

Vulnerability scanning for MS17-010 / 4013389 / WannaCry using OpenVAS in a Docker Container

Chris Bradford — Wed, 24 May 2017 22:44:44 +0000

For instructions on how to install Docker on Ubuntu see my post here: /linux/installing-docker-on-ubuntu-16-04-lts-16-10/

Updated 31/05/17 to include Ping Host and NMAP (NASL wrapper) tests due to feedback around reliability of results without these tests enabled.

Following on from my previous post around MS17-010 / 4013389 vulnerability patching assurance I thought I’d share a more robust scanning and reporting tool that is simple to deploy and use, OpenVAS. The deployment/ configuration of which is made even simpler through the availability of a Docker Image.

Assuming you have an Ubuntu 16.04 server/ client with the docker engine installed, use the following commands to get OpenVas up and running:

docker pull mikesplain/openvas:9

docker run -d -p 443:443 --name openvas mikesplain/openvas:9

# *** Alternatively *** use the host machines IP address rather than the docker0 interface/ a NAT'd address as above.

docker run -d --net host -p 443:443 --name openvas mikesplain/openvas:9

Next, browse to https:// and login, using default credentials of admin / admin :

Now, from the top menu, browse to Configuration > Scan Configs

Click the “sheep” (clone) button next to empty

Hit the spanner icon at the top of the window:

Name the Scan Config “MS17-010 Vulnerability Check” or something else meaningful:

Scroll down to “Windows : Microsoft Bulletins” and hit the spanner icon next to this:

Search for 4013389 (the relevant MS ID), enable all instances for the scan and click save:

As per comments via this post, also enable the Port Scanners | Ping Host and NMAP (NASL wrapper) tests.

Click Save, then click save again.

Now browse to: Scans > Tasks

Click the “Pink Wand” icon: New > Advanced Task Wizard

Name the task and select the new scan config you just created. Specify IP, subnet etc you want to scan. Hit “Create” to start the scan for this specific vulnerability.

Check the reports as the scan progresses, anything identified needs to be patched, or hardened/ isolated if it is older than those O/S editions that this patch was released for.

Happy hunting…

MS17-010 Vulnerability Checking with PowerShell and Nmap

Chris Bradford — Mon, 22 May 2017 13:28:55 +0000

There have been several MS17-010 PowerShell scripts that have emerged over the last week or so, I wanted to call out a couple in particular, aimed at assurance/ understanding vulnerability within a network rather than the remediation/ clean-up.

The first uses Nmap to identify individual IPs/ hostnames that are vulnerable to MS17-010 exploit: https://gist.github.com/iwikmai/65b8a5b882e782d78fc5f466dfd2cde4

Using Nmap is important as simply installing the patch itself without a reboot is not enough to protect against this vulnerability. This script uses Nmap to confirm that this exploit is no longer available on a per-target basis, rather than simply looking for an installed hotfix.

The second script is good for checking that machines have the patch itself installed: https://github.com/kieranwalsh/PowerShell/blob/master/Get-WannaCryPatchState/Get-WannaCryPatchState.ps1

No doubt you’ll come across scripts that help you deploy the patch and even decrypt/ clean-up WannaCry itself – certainly lots of interesting reads in recent days.

Microsoft Local Administrator Password Solution (LAPS)

Chris Bradford — Thu, 29 Sep 2016 23:28:33 +0000

Managing local Administrator passwords on computers can be painful, especially in a large estate. Good practice is for each device to have its own, unique, local Administrator password to stop “lateral movement” of malware / reduce risk – in practice, few organisations actually achieve this.

I recently came across a Microsoft solution geared towards addressing this problem – the Local Admin Password Solution:

The “Local Administrator Password Solution” (LAPS) provides management of local account passwords of domain joined computers. Passwords are stored in Active Directory (AD) and protected by ACL, so only eligible users can read it or request its reset.

In terms of supported operating systems, at time of writing requirements are very flexible in respect of DCs and target Operating Systems:

Active Directory:
> Windows 2003 SP1 and above

Managed machines:
> Windows Vista with current SP or above; x86 or x64
> Windows 2003 with current SP and above; x86 or x64 (Itanium not supported)

For more information, and, to download the tool itself click here: https://www.microsoft.com/en-us/download/details.aspx?id=46899

ConfigMgr : Adding KMDF 1.11 (KB2685811) to Build and Capture Taks Sequences

Chris Bradford — Tue, 27 Sep 2016 09:38:43 +0000

Download the KMDF 1.11 driver for X86 and X64 architectures using this link: https://support.microsoft.com/en-us/kb/2685811

Extract the MSU files using the commands:

mkdir C:\Temp
mkdir C:\Temp\Windows6.1-KB2685811-x86\"
mkdir C:\Temp\Windows6.1-KB2685811-x64\"

expand –f:* kmdf-1.11-Win-6.1-x86.msu "C:\\Temp\Windows6.1-KB2685811-x86\\"
expand –f:* kmdf-1.11-Win-6.1-x64.msu "C:\\Temp\\Windows6.1-KB2685811-x64\\"

Create a ConfigMgr package (not Application) as indictaed below:

Package name: Microsoft KMDF 1.11 Hotfix

Folder structure / contents:
\X86\Windows6.1-KB2685811-x86.cab (extracted from downloaded MSU, as above)
\X64\Windows6.1-KB2685811-x64.cab (extracted from downloaded MSU, as above)

Ensure content for this package is distributed to all of your DPs prior to continuing.

Now we will modify your “Build and Capture” Task Sequence.

Create a new folder/ group just prior to the “Setup Windows and Configuratipn Manager” task:

Below, I have detailed actions for x64 architecture, replace X64 with X86 for 32-bit.

This group will contain two actions:

Run Command Line: Create Temp Folder
Command: cmd.exe /c mkdir %OSDSystemDrive%\Temp
Package: No Package

Run Command Line: Inject KMDF 1.11 x64
Command: cmd.exe /c X:\windows\system32\dism.exe /ScratchDir:%OSDSystemDrive%\Temp /Image:%OSDSystemDrive%\ /Add-Package /PackagePath:%_SMSTSMDataPath%\Packages\M010038D\X64\Windows6.1-KB2685811-x64.cab
Package: Microsoft KMDF 1.11 Hotfix

This driver will now be injected automatically everytime you re-create your master image via the Buld and Capture Task Sequence.

Journey to the Surface (Pro) and Back – A Surface Pro 4 Review

Chris Bradford — Sun, 29 May 2016 21:06:43 +0000

My wife would be the first today that I am a “geek.” New hardware, new devices, new technology trends – I’m there, working in IT for many years technology is both my work life and home life and I love it.

So, when Microsoft announced the original Surface series I was thrilled at the idea of a what looked to be a “useful” iPad. I appreciate my definition of useful will be different to your definition, so take that statement with a little salt.

My definition of useful;

Small, lightweight and thus travel friendly
Sharp, bright screen
Battery life of ~5+ hours (ideally 8+)
Able to run Microsoft Office (not then as universally available as it is today)
Connect a mouse for remote support/work and, if necessary, a keyboard/external monitor for extended use

The challenge that MS couldn’t get away from, and still cannot today, is the “competition” – the iPad. I say “competition” as this is, in my opinion, an unfair comparison. A Intel-based, PC capable device, vs a mobile OS, ARM-based device.

In 2012, when the original Surface was lunched I’ll be honest, I’d drunk the cool-aid. I went to TechEd that year and was able to pick-up a heavily discounted Surface RT. The excitement soon waivered, namely because

The device had limited use, it was neither a tablet or a PC and as a result it was not good at being either

The “Touch” keyboard was hopeless – even after really trying to get used to it
The app ecosystem was terrible
The proprietary power connector (why?!) and supplied charger had a very short cable – I always wondered why MS introduced a proprietary connector for charging, and why they continue to use one today
There was no LTE/3G connectivity

I loved the concept though, and really thought MS could drive a serious makeover of what was a relatively dull PC market at the time. Windows 8 wasn’t helping the PC market, however this new OS actually made “sense” on these Surface devices.

Fast forwards a few months and 2013 saw the release of the Surface Pro, an Intel-based x86_64 device, capable of running office and other applications I had been used to over the years. Of course, it wasn’t without it’s compromises

Battery life was terrible – in my experience, much worse than advertised
The Type Keyboard, whilst much better than the Touch Keyboard would often disconnect
The device itself was bulky, heavy in comparison to the competition. I often remember my colleagues at the time mocking the devices girth and weight
No LTE/3G connectivity

Most of the above were big problems. The device let me down on several occasions due to the short battery life, charging during meetings or conferences was painful due to the short power lead and it was not much lighter than some of the better laptops at the time.

Cue… the Surface Pro 2 and the Surface 2. I owned the Surface Pro 2, opting to bypass the Surface 2 as this was still an ARM-based device – in a limited App environment it just didn’t seem like a “useful” device. The Surface Pro 2 on the other hand was a new device… therefore I had to have it. Consumerism at its finest.

The device was still bulky, its battery life was still mixed and, when coupled with the proprietary charger/short cable, was becoming a growing concern with the increased amount of travel I was doing with work. I continued to experience keyboard connectivity issues and for whatever reason MS still refused to offer an Intel-based product with LTE/3G connectivity.

It still felt as if MS didn’t quite know how to respond to the struggling PC market. It had its fingers in the so many pies – new PC hardware, mobile Operating systems and devices, the a new “touch friendly” PC operating system market, new “modern” apps.. The list went on. The issue for me here isn’t the variation, or the development, but the incoherency of how this stuff didn’t quite come together. It all felt a little rough around the edges.

With the obvious limitations, especially in terms of LTE/3G, I often found myself asking who these devices were being built for – were they simply an example of the possible, or were they customer-focused, designed to work for business? Still, I was a stalwart defender of the product line and it’s best bits – even now I genuinely feel that MS has helped to push the OEMs into producing more and more innovative devices.

May 2015 saw the release of the Surface Pro 3; this was exciting (of course it was, it was a new device!). It was thinner, lighter, faster and had better battery life. The screen was (a lot) better, and the aspect ratio made “sense.” It felt as if Microsoft had started to listen.

LTE/3G, for some reason, connectivity was still off the cards – ironically this was a big show-stopper for my then current employer moving to this form factor/device.

Windows 8.1 continued to, in my opinion, work well on these devices, despite the frequent keyboard disconnects.

Whilst battery life was better, it still wasn’t great – a full work day was a big ask. I’d find myself with the equivalent of electric vehicle “range anxiety.” The charger was still proprietary, and short, ergo not useful when in meetings/conferences.

The Windows 10 release, and eventual upgrade led to issues that weren’t there with 8.1.I started to receive video driver issues, the Surface Pen had problems. Ironically, the look and feel was fantastic, it just felt like a thin veneer where, below the surface (pun not intended), I felt like I was running something that was par-baked/pre-release. Still, it would be better with the next release right?

Just 6 months later, in October 2015, the Surface Pro 4 and Surface Book were released. I opted for the Surface Pro over the Book – it was smaller, lighter and suited my bike-based commute and travel requirements.

This was the device that finally pushed me away from the Surface series.

I had “wake” issues, where the device refused to power on from a sleep state having simply closed the Type cover. Windows Hello would frequently stop working – the red indicator light on the camera would get stuck, effectively indicating the camera had locked up.

The display driver would crash frequent and often, but most infuriating of all, the keyboard disconnects were now prolific. I’d often sit down for a meeting and find myself disconnecting and reconnecting the keyboard two or even three times before it would start to respond – even the backlight wouldn’t function. Of course all of this assumes the device actually woke up.

My once stalwart defence was becoming embarrassing, despite persistence across four generations of what I had hoped to be a game-changing device.

Coupled with the now ever increasing “Continuous Delivery” model which is driving Windows 10 updates at a much faster release cadence – at times I would arrive at the office on a Monday morning, power the device up only to find after a couple of minutes it was performing a firmware update, at 0900, on a Monday.

The wake issue is better now than it was, but it’s still not 100%. The display driver is better than it was, but it is far from 100%. Again, the whole experience just doesn’t feel quite finished.

What’s really sad for me, as a defender of this device and form-factor, had the hardware issues been worked out, and the software been reliable on launch, this was the game changer the stagnant PC market has been waiting for. It’s innovative, its desirable, it just needs to work…

No doubt I’ll be back at some point, but for now I’m back using a Folio 1020 laptop – grateful that it wakes up and the keyboard works, every time.

ConfigMgr : Multilanguage Office 2016 Click-to-Run (C2R)

Chris Bradford — Sun, 29 Nov 2015 17:27:58 +0000

Download office using the following configuration.xml file – make sure you include ALL languages you will want to use across devices in your environment – don’t worry though as we’ll use this to stage more streamlined versions as required – the idea here is that you create one source to rule them all – i.e. a single source with all language packs pre-downloaded. More info on how to download here: /microsoft-articles/34-configmgr/2118-configmgr-deploying-office-2016-click-to-run-during-osd

Now create this dynamic PowerShell script – we’ll call this during OSD or package deployment specifying a argument for the secondary language you need. This script should be named “_Install.ps1” and should be in the root of the package you create, along with the contents of the downloaded Office C2R.

Param(
  [string]$language
)
# Build dynamic XML file text - needed as without specifying the SourcePath Office install hangs
$currentLocation = Split-Path -Parent $MyInvocation.MyCommand.Path;
If ($language) {
$text = @"

  
    
      
	  
    
  
  
  
 
"@
}
Else {
$text = @"

  
    
      
    
  
  
  
 
"@
}
# Output XML file
$text | Out-File 'dynamic_configuration.xml'
# Execute setup, using dynamic XML file
start-process -wait -WindowStyle hidden setup.exe -argumentlist "/configure dynamic_configuration.xml"

You can call this from within a ConfigMgr 2012 R2 SP1 Task Sequence using the “Run PowerShell Script” step, configured as below – note I use a TS variable to pass “fr-fr” or “de-de” to the dynamic XML file creation. You could simply type the language needed and work out the logic to get the right package to the right machines a different way.

Name: Run Script: Install Microsoft Office C2R (MUI)
Script name: _Install.ps1
Parameters: -language %OSDSecondaryUILanguage%
Execution Policy: Bypass

ConfigMgr : Deploying Office 2016 Click to Run during OSD

Chris Bradford — Sat, 28 Nov 2015 17:44:11 +0000

Click to run offers a relatively pain-free way of packaging Office 2016, but it does present some challenges when deploying via SCCM or similar enterprise tools. Follow the steps below to enable deployment of Office 365 via SCCM 2012 – I’ve tested this against Windows 7, 8.1 and 10 – YMMV.

1. Download and install the Office 2016 Deployment Tool from: https://www.microsoft.com/en-us/download/details.aspx?id=49117

2. In the same directory as your new setup.exe create new file named configuration.xml – contents:

3. Download Office 2016 using a command prompt in the Office 2016 Deployment Tool directory, via the following command: setup.exe /download configuration.xml

4. Within SCCM create a new package or application from contents of new “Office” folder within the directory you executed the command from

5. Create a PowerShell script “_Install.ps1” within the root folder of the Office 2016 package/application – contents below – and call this scritp from a “Run PowerShell Script” task within your Task Sequence.

# Build dynamic XML file text - needed as without specifying the SourcePath Office install hangs
$currentLocation = Split-Path -Parent $MyInvocation.MyCommand.Path;
$text = @"

  
    
      
    
  
  
  
  
 
"@
# Output XML file
$text | Out-File 'dynamic_configuration.xml'
# Execute setup, using dynamic XML file
start-process -wait -WindowStyle hidden setup.exe -argumentlist "/configure dynamic_configuration.xml"