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.

Importing updates into WSUS on Server 2016 fails

I ran into a situation recentlly where i needed to import a specific update from the Windows update catalog into WSUS (and in turn into SCCM)

I opened WSUS, clicked on “import updates”, seletced my update and was presented with

“This update cannot be imported into Windows Server Update Services, because it is not compatible with your version of WSUS”

Strange…. WSUS on 2016 is extremely similar to WSUS on 2012 R2… so whats going on here ?

Long story short… there seems to be issue with the url passed by the WSUS console when you click “import updates” to the browser.

When you first click on “Import updates”, IE will open (or you will use IE because it makes importing updates into WSUS easier) to

http://catalog.update.microsoft.com/v7/site/Home.aspx?SKU=WSUS&Version=10.0.14393.2248&ServerName=<servername>&PortNumber=8530&Ssl=False&Protocol=1.20

Simply change the last part “1.20” to “1.80” – and importing updates will now work

i.e

http://catalog.update.microsoft.com/v7/site/Home.aspx?SKU=WSUS&Version=10.0.14393.2248&ServerName=<servername>&PortNumber=8530&Ssl=False&Protocol=1.80

The importance of cleaning up WSUS – even if your are only using it for SCCM

In the distant past, we would generally say to clients “Leave WSUS admin alone – the SCCM settings will take precedence, so there is no point in using it”

As the years have passed, and the number of updates available has grown considerably, this is no longer the case. The SCCM settings still take precedence, however the pure number of updates has gotten so large that it can cause performance issues for the SCCM server – and even the IIS timeout to expire when SCCM is syncing updates. This generally results in and endless loop and 100% CPU for w3wp.exe.

Unfortunately, trying to list the updates in the WSUS console will often lead to the console crashing and the dreaded prompt to “reset server node”.

The best way to address this, isn’t really one of the many articles you will find by googling “sccm high CPU w3wp.exe” (or similar). Generally these will suggest modifying a number of entries in your IIS config to increase time outs, etc – these can assist, but they don’t really address the root cause of the issue – which is simply the huge number of updates.

The best way to resolve this is to simply reduce the number of updates shown in WSUS. This will reduce your memory usage, reduce the number of updates that SCCM has to scan each time, and generally put less load on your server.

There are two ways you can go about this:

 

The manual method

If you have the resources available, I’ve found increasing the RAM and CPU count on the SCCM server temporarily can help allevate the issue of the “reset node” issue.

Once you get in (it may take a few attempts), go to ‘updates’ > ‘all updates’, set the search criteria to “Any except declined” and “any” and hit refresh. Once loaded, add the “supersedence” column to the view and sort by that.

Decline all updates that are superseded. If you don’t clean up regularly, this number could be very high.

After this, you can create views to decline updates for products you no longer use (e.g. Windows 7 and Office 2010) or search for things including “beta”, “preview” and “itanium” and decline those updates as well.

After all that is done, run the server cleanup wizard. You will likely need to do this a number of times, as if your server is struggling already, this also will struggle to complete (and it seems to be quite poorly coded to handle large numbers of updates on low end servers)

 

The scripted method

A guy called “AdamJ” has written a very useful script which you can get at https://community.spiceworks.com/scripts/show/2998-wsus-automated-maintenance-formerly-adamj-clean-wsus . I know, I can see some of you recoiling at the suggestion of using a user submitted spiceworks script… they do have a whole bunch of people (just like the MS forums) suggesting to use “sfc /scannow” for anything and everything – which is a sign of a non-enterprise tech that has NFI… however, this script is really very good – and something I’ve been using for approx 2 years, with nothing but good things to say about it.

You can run it with the “-firstrun” parameter and it will, by default, clean out superseded updates – which is the main cause of huge update numbers, but it will also grab the ever annoying itanium, preview and expired updates. At approx line 629 of the script, you can also configure it to remove IE7,8,9,10 updates, Beta updates etc (or if you are one of the few people in the world with itanium, keep itanium updates!).

This script, unlike the console, will keep plugging away… and if it should happen to get stopped for whatever reason, will resume where it left off.

When removing obsolete updates, I have seen some clients (with lower spec servers) where this process can take a long time, so long that you may have to leave it overnight (or over the weekend), and sometimes restart the process.

This process will get you a fair chunk of the way, and allow you to then open the WSUS console and decline further updates, such as products you no longer use (Windows 7 and office 2010 are reasonably common ones these days), x86 updates if you have an all x64 environment, and in the case of Win 10, updates that no longer apply to you (e.g. if your entire fleet is on Win 10 1609 and 1703, you don’t need the 1511 updates)

After all this is complete, you do need to run the server cleanup wizard again – which does frequently crash and end up with the “reset server node” error. So you can re-run the WSUS cleanup script, or simply run the server cleanup wizard multiple times.

 

My experiences using these methods

I’ve found that in environments that were previously at 100% CPU, they start working again, and environments that were massively over-specc’d that didn’t have the high CPU issue went from using 6gb of RAM for the w3wp.exe process down to 500mb. This will obviously vary from environment to environment.

After this process is completed, you should be able to get into the WSUS console and run the server cleanup wiazrd, without crashes.

If you’re interested, you can also sync SCCM software updates and look at the wsyncmgr.log and see the far smaller list of updates it will sync against now.

Longer term, the AdamJ script does have monthly options that you can schedule in, or for our clients that are uncomfortable with that, simply get in and clean up once every 3 months or so, so you list of updates doesn’t get out hand.

The first cleanup is the biggest, after that, performing the same operations once every 3 months is plenty, and if you forget about and it happens to be once every 6 months instead, you’ll still be fine.

 

Taking it a step further – shrinking the SUSDB

One of the things which the AdamJ cleanup script does is truncate the SQL table “tbEventInstance” which uses up the majority of space in most WSUS databases that have been in use for a while.

If you are not comfortable with a script doing this, you can connect to the database and execute the following query against the “SUSDB” database – “truncate table tbEventInstance”.

If the DB is on a full version of SQL (which, if your running SCCM, i would argue the SUSDB should be on the same SQL instance, rather than installing an additional windows internal database), you can then create a maintenance plan to reindex, shrink etc the database.

If you are using Windows internal database, you can still install SQL management studio, then connect to “\\.\pipe\MICROSOFT##WID\tsql\query”, from there you can execute the truncate, shrink the database etc. Keep in mind that you cannot use maintenance plans with Windows internal databases.

 

What about large enviornments where you do require a wide range of updates ?

In large environments, you may not be able to decline entire product sets for extended periods (e.g. its relatively easy to move everyone onto Windows 10 (and get rid of all Win 7) for 2,000 PC’s, but not so easy for 50,000 PC’s), however, many of the points in this article still hold true.

  • The largest reduction in updates will still come from superceded updates
  • Language packs are another area where there’s lot’s of opportunity for reduction (e.g. if you require english and french – there are many other languages that can declined)
  • Ensure your SUSDB is on your full SQL instance…. that way you are running one less database instance (and therefore utilising less resources) and also have maintenance plans at your disposal
  • Use a maintenance plan to keep your SUSDB database optimal

 

SCCM Update Cleanup

It’s also worth noting that once the SUSDB has been cleaned up, SCCM will execute its own cleanup after the next sync. This cleanup removes obsolete Update CIs (Configuration Items) that corresponded to the items removed from the SUSDB. In most environments, this isn’t usually something noticeable, however in severely under resourced SCCM servers it can cause its own set of problems (though there’s not a huge amount you can do about it other than wait). This will generally present as the SCCM console locking up while it’s doing back-end SQL processes – and if you look at the SQL threads, you’ll see a WSUS related one blocking all other threads. Realistically your best option to resolve this is to increase the resources available to the server – and if that isn’t a possibility, settle in for a long wait!

Microsoft products – consolidated table of end of life dates

Microsoft product end of support dates are sometimes not easy to find and its not getting any better with the “current branch” releases and cloud solutions being governed by the Modern lifecycle policy.

The Modern lifecycle policy page further links to 3 product catagories, O365, Cloud platform and Dynamics. Unfortunately, its not clear (at least to me) how this helps with products such as SCCM current branch (be it 1606, 1702, 1706, 1710 or 1802) – however this information is available at another location

Likewise with the “traditional” products, most end of life information is available here – but to say that the information is difficult to search through is an understatement.

It also sometimes lacks detail, for example, there is no metion of the differing support for Windows 8.1 without update 1 and with update 1.

We have a number of clients that take the approach that while a server is running, to leave it there – and while I may personally not like this approach (i prefer to roll through the OS upgrades as they come out) – they have a valid approach and end of life information is important for them.

Keep in mind that everything listed below is end of extended support, not mainstream support – and i have taken some liberties (e.g. assumed that windows 8.1 is 8.1 with update 1)

Windows 10 dates have been sourced from the product lifecycle page, however this blog entry states than an additional 6 months has been granted to displayed Windows 10 versions.

If you find the below useful – cool. If i’ve got something wrong, or missed something that is key (in your opinion), please leave a comment.

 

ProductEnd of life date (end of extended support)
Windows 2003 SP2July 14, 2015
Windows 2008July 12, 2011
Windows 2008 R2 SP1Jan 14, 2020
Windows 2012Oct 10, 2023
Windows 2012 R2Oct 10, 2023
Windows 2016Jan 11, 2027
Windows XP SP3Jan 11, 2011
Windows Vista SP2April 4, 2017
Windows 7 SP1Jan 14, 2020
Windows 8Jan 12, 2016
Windows 8.1 with update 1Jan 10, 2023
Windows 10 RTM (1507)May 9, 2017
Windows 10 1511Oct 10, 2017 (End of support)
April 10, 2018 (additional servicing for enterprise and education)
Windows 10 1607April 10, 2018 (End of support)
Oct 9, 2018 (additional servicing for enterprise and education)
Windows 10 1703Oct 9, 2018 (end of support)
April 9, 2018 (additional servicing for enterprise and education)
Windows 10 1709April 9, 2019 (End of support)
Oct 8, 2019 (additional servicing for enterprise and education)
Office 2007Oct 10, 2017
Office 2010 SP2Oct 13, 2020
Office 2013April 11, 2023
Office 2016Oct 14, 2025
Lync 2010April 13, 2021
Lync 2013April 11, 2023
Skype for Business 2015April 11, 2023
Exchange 2010 SP3Jan 14, 2020
Exchange 2013 SP1April 11, 2023
Exchange 2016Oct 14, 2025
Forefront TMGJuly 12, 2011
Sharepoint 2010July 10, 2012
Sharepoint 2013 SP1April 11, 2023
Sharepoint 2016July 14, 2026
SCCM 2012 SP2July 12, 2022
SCCM 2012 R2 SP1July 12, 2022
SCCM 1606July 22, 2017
SCCM 1610Nov 18, 2017
SCCM 1702March 27, 2018
SCCM 1706July 31, 2018
SCCM 1710May 20, 2019
SCCM 1802Sept 22, 2019
SCVMM 2012 SP1July 12, 2022
SCVMM 2016Jan 11, 2027
SCOM 2012 SP1July 12, 2022
SCOM 2012 R2July 12, 2022
SCOM 2016Jan 11, 2027
SCORCH 2012 SP1July 12, 2022
SCORCH 2012 R2July 12, 2022
SCORCH 2016Jan 11, 2027
SCSM 2016Jan 11, 2027

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.

Preparing to update for Intel® Management Engine Critical Firmware Update (Intel SA-00086)

Intel released a security advisory yesterday (22/11/2017) advising of vulnerabilities with their management engine firmware – which can he found here

The reason why this is concerning for corporate customers is that basically every PC, Server and laptop that you have, most likely will be exposed, as the vast majority of corporate level hardware contains this hardware.

Intel has provided a detection tool available at https://downloadcenter.intel.com/download/27150. Contained within is a couple of applications, the GUI version will probably be handy for those orgs with only a handful of makes and models – where-as the command line tool will be more useful for larger organisations to run and centralise results via tools such as SCCM.

 

The original page contains links for various vendors update, the downside is that there doesnt seem to be many patches as yet, as per this page (at the time of writing, all Dell entries are marked as “TBD”, where-as Lenovo lists a target date of 24/11/2017)

 

So, what can you do while waiting for the patches to be released?

  • Test your systems using the provided tool to see if they are vulnerable. Testing at least one of each make/model will give you a good idea what you will need to target
  • Setup SCCM collections ready to go, which would entail
    • A collection for each make and model (I imagine many places would have this already)
    • A series of collections which each include one/make model and the criteria “AMT Agent – Flash is NOT equal to <insert version number of patched FW – once released>” – This will enable you quickly identify machines which need to be targeted with the update
    • (Please note the above is an assumption, some vendors may patch this via a BIOS update, in which case, the BIOS version may be the identifier instead)

 

Please post a comment if there are any questions – and ill update thios post once the patches are released – if there are any gotcha’s we run into.

KB4038777 fails on some Windows 2008 R2 servers

Recently, we had an issue where KB4038777 was failing to install on some Windows 2008 R2 servers, but was fine on others.

Sometimes, this indicates that the “maximum run time” on a patch has been set ludicrously low (generally 10 minutes) on a specific patch – and the servers that it is failing on, are those that don’t perform so well – and therefore time out.

In this case, the patch was failing with the following line in the CBS.log

Failed to find file: x86_microsoft-windows-directwrite_31bf3856ad364e35_7.1.7601.23688_none_c657164201eacd8d\DWrite.dll [HRESULT = 0x80070002 – ERROR_FILE_NOT_FOUND]

We tried a number of things to “fix” this, including comparing file versions of Dwrite.dll, cleaning out the softwaredistribution cache, disabling AV etc – to no avail.

After a few hours, we found that installing the “desktop experience” feature (which requires a reboot), then running a disk cleanup (including windows updates) on the server then allowed us to install this update.

Its not an ideal “solution” – and quite frankly – all Windows 2008 R2 server should be in the process of being decommissioned… but aside from that, it seems that admins have the option of

a) installing desktop experience, rebooting, then running a disk cleanup

b) waiting for next months rollup – which may not have the same issue.

 

SMB 1 no longer installed by default in Win 10 1710/Server 2016 (next release)

https://support.microsoft.com/en-us/help/4034314/smbv1-is-not-installed-by-default-in-windows-10-rs3-and-windows-server

As per the link above, SMB 1 will no longer be installed by default in Win 10 1710 (which, given the release date, I’m guess that’s what it will be called) or the next version of Server 2016 (whatever that ends up being called).

Considering the recent-ish SMB1 targeted attacks, this isn’t surprising – and is a good move in my opinion. Issue is of course, the companies likely to hit by SMB1 (or other old-school attacks) are likely to not be up to date with their patching and even less likely to be up to date with OS versions – so it wont help secure the more vulnerable networks out there….