Creating large stand-alone media from SCCM – issues when the HP SPP 2018.03 is a package in the TS

We often create one task sequence for all workstation builds and another for all server builds, utilising task sequence variables to perform the decision making within the task sequence.

One of the downsides of this is that the task sequence binaries can get quite large, especially for server builds where we have current and legacy versions of the HP SPP, the Dell SUU and (at a minimum) server 2012 R2 and server 2016.

This isn’t an issue for network based builds, as non-required content is simply skipped, however, for media builds, it can lead to 40GB+ requirements, which the SCCM console doesnt handle well.

This is where Rufus comes in.

Rufus can help out by allowing use of larger hard drives (just tick the “list USB hard drives” option) and can apply bootable iso’s generated by SCCM (utilising the “unlimited size” option) to a USB hard drive.

This has been incredibly useful for us in the past, utilising large hard drives as USMT stores at slow link sites for client deployment.

In this instance, ive been using Rufus to apply a 50GB server build iso to a hard drive, but keep getting presented with a warning

“This ISO image seems to use an obsolete version of ‘vesamenu.c32’. Boot menus may not display properly because of this.”

Irrevelant of how you proceed (allow Rufus to download an update or not), the drive is not bootable.

Upon investigation of the rusfus logs and the resultant media, i found that syslinux.cfg was actually pointing to my HP SPP package.

This forum post then confirmed that Rufus is finding a syslinux.cfg, assuming that it is “real” bootable media and hence the ‘vesamenu.c32’ prompt.

After a few hours of troubleshooting and trying to get around it, i simply removed the “usb” and “system” folders from my HP SPP packages (as we wont be booting to it ever, its only for use in SCCM), re-created my standalone media iso – then used Rufus to write the bootable iso to the USB HDD, this time with no issues.

I realise this is a fairly obscure issue , but hopefully it helps someone.

 

 

Speed up offline servicing

Currently i am creating some server builds for a place which will be deploying large numbers of servers over the coming months.

One of things that is/was taking up a great deal of time was offline servicing for the base OS, primarily because the SCCM server is currently sitting on a virtual environment with disk that is struggling. With 2016, this isn’t so bad, as due to cumulative updates, there are only a few updates to be installed. With 2012 R2 however, there is a large number of updates – and the process continually fails due to the poor performance of the server.

One of things you can do to speed this process up is to remove unused images from your wim.

Both Server 2012 R2 and 2016 come with 4 images (with an index of 1 to 4) within the install.wim. These generally correlate with:

  • Index1 – Server 2012R2/2016 standard core
  • Index2 – Server 2012R2/2016 standard desktop experience
  • Index3 – Server 2012R2/2016 datacentre core
  • Index4 – Server 2012R2/2016 datacentre desktop experience

If you view Logs\OfflineServicingMgr.log during an offline servicing operation, you will notice lines that state things such as:

Applying update with ID xxxxxx on image at index 1

Then the same update will apply to image 2,3 and 4. In this enviornment, we are not deploying server core, so we only need indexes 2 and 4 (standard and datacentre with desktop).

We can view the indexes available within the wim by typing:

dism /get-imageinfo /imagefile:E:\<path to wim>\Install.wim

Then, if you dont need indexes 1 and 3 (as we dont in this scenario)

dism /delete-image /imagefile:E:\<path to wim>\Install.wim /index:1
dism /delete-image /imagefile:E:\<path to wim>\Install.wim /index:3

Now when you use offline servicing, each update will only be compared against 2 images, instead of 4, significantly reducing the processing time/disk usage, especially for 2012 R2 (where there are a large number of updates to apply)

This can also be used for client OS’s, such as Windows 10.

One important note – this will not reduce the size of the WIM. It will simply remove the index and save you time for offline servicing.

If your image is already in SCCM, then you must

  1. Go to Software Library | Operating systems | Operating system images
  2. Right click on the appropriate image | properties | Images tab
  3. Click on “reload”, then notice the dropdown has been reduce from 4 index’s, then hit “ok” to exit.
  4. Go into your task sequence
  5. Update the image index as required.

Meltdown and Spectre patches available

Hi all,

For many of you that switched off over the xmas break (like me), you may have missed that there are now patches (released Jan 3rd 2018) for the creatviely (almost bond movie like) named vulnerabilities of “meltdown” and “spectre”.

You can find more detail on these Vulnerabilities  here – https://meltdownattack.com/

Advice for Microsoft client OS’s is here – https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in . The page still indicates to “contact your vendor” for microcode updates – which isnt going to overly helpful for standard end-users.

Advice for Microsoft server OS’s is here – https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution. There is additional work required over and above the patch for Remote Desktop and Hyper-V servers. Additionally, Windows server 2008 and 2012 are not yet patched, only Server 2008 R2/2012 R2/2016/1709 – read into that what you will.

The register has a good article (as they do most of time) cutting through the intel PR bullshit. Importantly, there has been various reports of performance impacts after installing these patches – but it is still too early to tell exactly how large/important those perfomrance impacts are.

There are links to many vendor advisories (which in turn have links to updates) @ https://meltdownattack.com/ – which is quite useful.

The patches and additional mitigations are fairly easy to implement if you have patching/management infrastructure in place – but if your company needs any assistance, we’re happy to help too.

Project Honolulu

With the recent release of Server 1709 (and the fact that it’s Server Core only), Microsoft have also recently released a preview of a new server management product. This product is currently code-named ‘Project Honolulu’, and is a light-weight web-based management console for Windows Server. Details of the original preview release can be found here.

In the past, when you wanted to manage remote servers (and especially Server Core instances), you either had to:

  • RDP in to configure it
  • Enable WinRM and use remote powershell
  • Enable WinRM and use a remote Server Manager instance from Server 2012 R2 or Server 2016

Depending on what you were trying to achieve, you also may have had to use remote consoles like Computer Management, Event Viewer, Storage Management, Certificate Management, Firewall Management – none of which are built in to Server Manager, but can be launched from there.

Based on initial impressions of Project Honolulu, it looks like Microsoft is trying to improve that experience, and it looks like they’re actually moving in the right direction.

As you can see from the above image, they’ve actually rolled a bunch of the above tools into a single interface – and the really surprising part, is that it’s actually fast. Not like Server Manager where sometimes it can take quite a while to refresh or load.

Obviously it’s not a complete product yet, and there’s a bunch of stuff in Server Manager that it would be nice to see in Honolulu – mostly around dashboards, additional tool sets (Active Directory tools, for example), and additional functionality in the existing tools.

Some of the things I found quite good with Honolulu:

  • The speed of loading remote information (event logs, services, etc)
  • The ability to remotely import a certificate PFX file without having to resort to painful powershell commands and scripts!
  • Set basic IP config on a remote server
  • Remote process monitor (graphical – not tasklist.exe!)
  • Remote storage management without setting up additional firewall rules
  • Virtual Machine dashboards/management. I haven’t had too much of a play with this so I’d say there’s stuff missing, but what’s there is actually quite good.
  • Remote Windows Update management (for those of you not using SCCM/WSUS to automate update installation)

Things it can’t do yet, but I’m hoping they add in:

  • Dashboards for overall status of servers
  • Search function for Registry viewing/editing
  • More settings for Services (eg: Logon details)
  • Editing of certificate private key permissions
  • Additional remote tools – such as Active Directory Users and Computers, DHCP, DNS, Remote Access Management, IIS, etc

If you’re interested in trying out Project Honolulu, it can be downloaded here. Installation instructions can be found here. To be honest, it’s a super simple setup – whether that changes in the future is yet to be seen!.

Note: remote management via Honolulu does require Windows Management Framework 5.0, so you’ll need to install that on non-2016 servers.

Server 2016 LTSC vs Server 1709 Semi-Annual

In September 2016, Microsoft released Server 2016. A couple months ago, they then released Server 1709. You’d be forgiven for thinking that Server 1709 is an upgrade to 2016 – because it’s actually not.

Much like Windows 10, Microsoft have gone down the path of having multiple ‘Channels’ with the Server products. Essentially:

  • Server 2016 is the server equivalent of Windows 10 LTSB (Long Term Servicing Branch)
  • Server 1709 is the server equivalent of Windows 10 CBB (Current Branch for Business)

Instead of using LTSB and CBB, the server OS’s are ‘Channels’ – so LTSC (Long Term Servicing Channel) and SAC (Semi-Annual Channel).

So what are the main differences?

Server 2016

  • Available in Standard, Datacenter and Essential editions
  • Available as Server Core, or Server with a GUI
  • 5 year mainstream support, 5 year extended support
  • New release expected every 2-3 years

Server 1709

  • Available in Standard or Datacenter (no Essential edition)
  • Only available as Server Core
  • 18 months mainstream support, no extended (much like Windows 10 CB and CBB)
  • Releases semi-annual

So why would you go with 1709 over Server 2016? In general, it depends on your use-case scenario. The largest improvements for 1709 are around Containers and Nano Containers (with Nano Server being deprecated), along with some Hyper-V. Obviously you’re going to be restricted to Server Core, but that’s not as big of a deal these days when you’re talking about built-in roles (due to significant improvements in remote management for Server 2016). In general, you’re only going to be considering 1709 (or any SAC release) in the following scenarios:

  • You’re looking to build a new Server Core server and you don’t mind upgrading it every 12-18 months
  • There’s specific features available in 1709 that aren’t available in 2016

For a full list of updated features in 1709, here’s the full list. There’s also a new management interface on the way, currently named ‘Project Honolulu’ – this may help with some of the Server Core management concerns.

A couple of gotchas:

  • If you’re using Automatic Virtual Machine Activation (AVMA) on Datacenter Hyper-V hosts, it doesn’t seem to work with Server 1709 – at this stage I’m unable to find official information about this, so it seems that you’ll need to use Manual Activation Keys (MAK) in the mean-time (or…ongoing).
  • You can’t upgrade from Server 2016 to Server 1709 (even if it’s 2016 Core) – much like you can’t upgrade from Windows 10 LTSB to CBB.

 

KMS Guide

Updated on :  11/08/2016 (Windows 10 KMS patch compatibility)
Relevant to:   KMS – all versions


KMS seems to be one of those things that is sometimes quite poorly understood – and many existing blog articles or pieces of documentation seem to gloss over important details (IMO). So, below is my attempt.

Concepts

 MAK – Multiple Activation Key

This type of key is intended to be used on multiple computers, but must be entered manually, via VAMT or in an SCCM task sequence. The activation process occurs once per machine either directly over the internet, via a MAK proxy or via telephone.

The MAK activation method is best suited for

  • Small organisations with 25 or less computers
  • Organisations who have certain machines which are not domain joined and/or do not connect to the business network regularly

KMS – Key Management Server(s)

A Key management server is a service which provides activation on behalf of clients. The KMS server is activated once, and in turn, clients will auto-locate and activate against the KMS service. (more about the details a bit later)

KMS Key – Key Management Server Key

This type of key is intended to be used on a Key Management Server to provide activation for clients and has a couple of important factors:

  • KMS requires what is called an “activation threshold”, which basically means that until you have more than 25 Windows 7/8/8.1 activations or more than 5 Windows Server 2008 R2/2012/2012 R2 activations, the KMS server is not active
  • To remain active, KMS clients must contact the KMS server once every 180 days. If it does not, the client will start showing activation messages.

Volume licensing

I would imagine that if you are reading this blog you are familiar with what volume licensing is. KMS and MAK are both used for volume licensing customers, you cannot activate retail or OEM operating system installs using these methods.


Decisions to be made prior to install

KMS or MAK

Many organisations we deal with use both.

If a machine is off the network for long periods of time or is not domain joined, use a MAK. (Please note that non-domain joined machines can still use a KMS, but usually there is a reason they are not domain joined, which may also mean they cannot access the KMS!)

For all the domain-joined, generally on the network machines, use KMS.

Choosing a KMS key

In my opinion, the Microsoft doco @ http://technet.microsoft.com/en-us/library/ff793412.aspx and http://technet.microsoft.com/en-us/library/ee939271.aspx makes it sound complex.

In short, go with the “highest” version of server you have available and it can then activate everything “below” it.

For example:

If you utilise the Server 2012 R2 standard key (KMS B), it can act as an activation server for 2008R2/2012/2012R2 standard and Win7/8/8.1, but it cannot activate datacentre editions.

If you utilise the Server 2012 R2 datacentre key (KMS C), it can activate other datacentre editions as well as all 2008R2/2012/2012R2 standard/datacentre and Win7/8/8.1.

“But I only want to license Windows 7 machines!” the response frequently comes back.

A KMS key will also license all products that are “lower” in the tree, so using a server 2012 R2 standard KMS key will allow you to license all windows 7 machines (as well as windows 8/8.1 and server 2008R2/2012/2012 R2)

“So why do I have a Windows 7 KMS key then?” is the next question

This is because it is an option to install a KMS on Windows 7, simple as that. This is something we would generally advise against, as most organisations that use a KMS would use it for their servers and workstations.

Choosing a KMS server – OS Version

Using the newest operating system in your environment generally means that you will not need to download additional updates or patches, so simply for that reason, we would recommend using the newest OS version you have available.

Choosing a KMS server – Server load & placement

The KMS role is a very low-load role and we have never had any issues co-locating it with other roles. One common pairing is placing the KMS role on the SCCM primary site server (for organisations of up to 5000 PC’s)

For larger organisations, we see various approaches. Some have dedicated KMS servers, some co-locate on other services.

This section is here because often people ask what the load is like and can be co-located with other roles. The short answer is, very low load service and it be co-located with anything that doesn’t need TCP 1688.

KMS publishing and load balancing

KMS, by default listens on port TCP 1688 and will (by default) publish a DNS SRV record to allow domain-joined clients to locate the KMS service. The record created is called _vlmcs

Windows 7/2008 R2 and above volume license operating systems automatically look for this DNS record.

SRV records have a weight and priority associated with them, and this, by its nature, allows multiple KMS’ to be published and administrators to use them in a round-robin scenario (same priority) or in a fault-tolerance scenario (different priorities)

It is possible to disable publishing for a KMS service, but this is not something we have ever done – and we are not quite sure of a scenario where this would be helpful (but this doesn’t meant there isn’t one!)

KMS1

Patching KMS to support Windows 10

In order to support Windows 10, you will need to patch your 2008R2, 2012 or 2012R2 KMS server as per

https://support.microsoft.com/en-au/kb/3086418


Office KMS

Office 2010 and 2013 have KMS add-on packs, that can be installed on an existing KMS server, these are available at:

Office 2010 KMS Host – http://www.microsoft.com/en-au/download/details.aspx?id=25095

Office 2013 KMS Host – http://www.microsoft.com/en-us/download/details.aspx?id=35584

Office 2016 KMS Host – https://www.microsoft.com/en-us/download/details.aspx?id=49164


Installing KMS + Office KMS step by step

These steps remain the same whether you are installing on Windows 2008 R2, 2012 or 2012 R2.

  • Decide which server will host your KMS. We recommend utilising the latest server version you have access to and the highest “edition” (at the time of writing, this is Server 2012 R2 Datacentre)
  • Logon to the server and open an elevated command prompt (this process will fail if you do not elevate the command prompt!)
    • C:
    • Cd windows\system32
    • Cscript slmgr.vbs /ipk <your product key, with the dashes>
    • Cscript slmgr.vbs /ato
  • You now have a KMS server
  • To verify the install and look at the number of currently activated machines
    • Cscript slmgr.vbs /dlv

KMS2

  • To install the Office KMS host (we will use 2013 in this example, however it is very similar to the 2010 process)
    • Download the KMS host update from the links above
    • Run the install
    • Enter your product key when prompted
  • To verify the install and look at the number of currently activated machines
    • Cscript slmgr.vbs /dlv all
    • Look for the appropriate office 15 (or 14) section

KMS3


Common questions

Question:            I want to move my KMS server, how do I move the activation database etc.?

Answer:               There is no activation database or anything that needs to be moved. Simply create a new KMS, install the KMS key and activate. Then decommission the “old” KMS by running slmgr.vbs –upk (uninstall product key) and then either delete the “old” _vlmcs record from DNS, or use slmgr.vbs -cdns

Question:            If my KMS client is off the network for more than 180 days, what do I do ?

Answer:               Simply re-attach it to the network, it will find the KMS server and renew its activation. If the client will regularly be off the network for more than 180 days, it would be wise to consider using a MAK for this client.

Question:             The SRV record has not registered in DNS.

Answer:                Sometimes a restart of the KMS service is required. Net Stop sppsvc then net start sppsvc

Sometimes, if an existing record already exists from a previous KMS, you may need to grant permissions over the DNS record, but frankly, its easier just to delete it and restart the KMS service (command above)

 


Common mistakes

Mistake: Using a KMS key on a number of client machines, either because the difference between MAK and KMS wasn’t clear, or my licensing person gave me the wrong key.

This can be quite easily fixed by changing the key on the affected clients :

Mistake: Deploying MAK keys in a task sequence, when you actually want to use a KMS.

If you want to use KMS, simply leave the product key section in your task sequence blank.

To “fix” existing clients, you will need to identify the machines with a MAK and install the default KMS key. The VAMT can be used to help identify and update these machines.

Mistake: Using the windows 10 KMS key on a server results in Error 0xC004F015

You need to use the server KMS keys on a server OS (as discussed above), please read the above article or visit https://support.microsoft.com/en-us/kb/3086418


Official doco references

Understanding MAK activation – http://technet.microsoft.com/en-us/library/ff793435.aspx

Understanding KMS activation – http://technet.microsoft.com/en-us/library/ff793434.aspx

Default KMS keys – http://technet.microsoft.com/en-us/library/jj612867.aspx

Deploying KMS – http://technet.microsoft.com/en-us/library/ff793409.aspx