Welcome – A letter from the Founder

Max Ranzau (aka RESguru 1)My name is Max Ranzau. I founded RESguru.com as a technical blog at the end of of 2008, dedicating my time and efforts towards creating better IT solutions through use of RES Software products in the enterprise. This site is the home of RCS – RESguru Consulting Services and is one of the primary go-to places for independent information, brain-share and tools for the workspace and automation engineers across the planet. I intend to keep it just that way.

If you are a new visitor, allow me a moment to welcome you properly, by immediately dispensing with the glossy marketeering and cut to the chase:

I am here to change Enterprise IT for the better.

I dare to guess that plenty suit & tie jobs have said something similar to you over the years. Nothing more or less, it’s the best one-liner by which it can be expressed what RCS does. Fact: it is exceptionally hard to explain what exactly and completely RES Software does in one sentence, without either becoming too vague or a long winded tale. Trust me on this, the good folks at RES Software have been grappling with this conundrum over the last 15 years: Having a stellar product suite, but no quick and singular way of explaining what it does!

I’m not going to pretend I’m driving around with the tomes of messaging wisdom* in my trunk. However, that is not going to prevent me from pitching in my two cents. As I see it, there are two main avenues of putting RES technology into context:

A) Presuming you’re technically oriented:  tbox

  • Get rid of complexity in  policy management, point-solution utilities and scripting. You know as well as I, that enough of this, or  by inheriting someone else’s hand-me-down environment, you’ll be up to your eyeballs figuring out what’s going on before you can make any changes.
  • Best profile+configuration management: Microsoft’s ways of handling configuration, both central (policies) and users (profiles) haven’t changed much in 20 years. The RES Suite will make profile management work smoothly for you.
  • Automation of complex script-less tasks across the entire IT estate, independently of domains. 150+ built in graphical tasks range from the simplest of deployment/configuration items to VDI, Mobile Device Management and Helpdesk, integrating with all the major vendors.
  • Workflows can be automated. The RES Suite will allow a company to define and execute workflows for almost anything that can be given to a user. It’s all about service. I usually tell my students that you can make workflows for giving employees their phones, forklifts or PhotoShop. It doesn’t matter as you model the business in the software, define who is qualified to automatically get or request what, assign any approvals to the workflow and then tie it all into the automation and configuration management where necessary. The real strength here is that all 3 products in the RES Suite talk together.
  • Documentation: As engineers, we just love cranking it out by the page, right? That was sarcasm! We love building great solutions but creating the associated paperwork afterwards is a hassle, even if it’s billable. For admins in terms of auditing, it’s the same challenge. The RES suite can do the documentation for you.

The RES Suite is like a well-organized Swiss Army knife, with 15.000+ blades. There are loads of other things the RES suite can do for you, and hopefully you’ll get a sense of this when you browse through the Tech Library of the RESguru site. There is over 100 and counting free practical how-to articles on how to solve common everyday problems with RES technology. Have a look at the intro page here for a proper introduction and tour around the site.

brfcaseB) Presuming you are financially oriented:

  • 60% savings on current support/helpdesk/administrative load is not unheard of.
  • 90% savings on external consultants camping in your data-center for months at a time as your own staff becomes able to do most things faster on their own. These kind of numbers been reported by some of my clients.
  • 20% more users typically on a central environment – just by virtue of efficient management.
  • No doctors with flashlights were involved in obtaining the numbers above! These are based on real RES projects that I have worked over the last 15 years. Having said that, obviously your mileage may vary in accordance with what you are trying to solve.
  • Business Processes – any organization has them. If your ever move people around, hiring or firing, the IT folks are usually the last to know, resulting in a long time before new employees can do what they’re paid to or exposing the company to unnecessary risk, by not closing down access properly when someone leaves. Sometimes I encounter customers who have custom-built and rather byzantine systems in place, some may be even manual of tossing around emails or even paper forms for approvals. As long as nothing changes you can maintain status-quo, however when the business requirements change, that’s where your costs become evident.
  • Appsense. Have you been struggling with their products for too long not being able to get things to work for you as promised? Spent countless hours having consultants in and out the door on break/fix missions? It’s time to stop and look at a Real Enterprise Solution.
  • Agility: What can be stood up in a few days by a engineer proficient in RES tech, can in most cases match and trump what would take a team of engineers using classic tools and methodology several months to implement.

The above should provide you with an decent idea of what is within the realm of the possible in the RES universe. RES technology is not rocket science, it’s just good product design and common sense for the modern enterprise. Covering the entire RES Suite, RCS offers the following on all VDI platforms, TS/Citrix, Laptops, Mobile devices, Windows and Linux environments:

  • Consulting, advisory and managed service agreements for new and existing RES installations
  • Scoping and technical presales assistance to integrators
  • Design and technical architecture documentation
  • Implementations, remote and on-site.
  • Technical competitive analysis. Here is a couple of examples.
  • Training, Education and Workshops in all RES products both online and on-site. See this for details.

For information on services, rates, schedules and anything else, reach out via the contact page , or call +1 610 462 2200. I look forward to talking with you.

With best regards,

Max Ranzau


Inside Workspace Manager 2014 SR2

By Max Ranzau



res-wm2014-00From the Nuts&Bolts Dept. Last week saw the release of Workspace Manager 2014 Service Release 2. You may have read the initial post over at RES, but as always here at RESguru.com we like to kick the tires and take it for a spin around the block. There’s several items in this release that are important to know about and I’m going to highlight some and give you my view on them. You can of course dust through the full release notes here as well. Let’s roll up the sleeves and get started:

Update considerations:

First of all, when rolling out the SR2 update, keep in mind that if you occasionally are using the Force Cache update on the agents view, you want to get all agents spun up to SR2 as quickly as possible. RES has changed some of the security underneath the hood, so a SR2 console can’t force-cache-update an SR1 agent, and vice-versa. You may recall the TCP/1942 port, which needs to be open on the WM agent. This port hasn’t changed, but the comms on it has. The schematic below explains it pretty well:



Finally! Batch Buildingblock processing:

Long awaited is the ability to export and manage buildingblocks. Many customers I’ve trained and worked with over the years had a hard time understanding why it was only possible to batch import buildingblocks with the current pre-FR2 /add parameter, but it wasn’t possible run a regular backup/export. Well, lo and behold we now have the following new commandline options for the WM console binary, pwrtech.exe:

  • /del – delete configuration items currently inside the WM datastore. You can use both a buildingblock, thereby mass-deleting items, or just deleting one item by specifying it’s GUID (this can be found by exporting a buildingblock and looking for the <guid> tag.)
  • /export – the droid we’ve been looking for. This allows you to export any one object by specifying a guid. It can also export all configuration objects of one or more given type keywords separated by commas.
  • /addresource – Allows you to upload any file as a custom resource to the WM datastore. With a /path parameter you can specify where in the custom resource folder structure the resource will be placed, or you can just leave it in the root. Using a /guid parameter you can overwrite an existing resource
  • /exportresource – Does pretty much the opposite. Either a /path inside the custom resource structure or a /guid to what you want to export can be optionally specified
  • /delresource – Deletes a custom resource. Again either /path or /guid can be specified.

A couple of random neuron-misfires here:

  • This makes me wish RES would put in a GUID field in the console (which can be copied from, thank you very much) on each and every last item, thus it would be quick to reference it as the alternative is to sit and munch through buildingblock XML. Besides, we already have the GUID visible on managed applications, so why not make it consistent
  • Also, these new commandlines gives food for thought. One could quite easily imagine future customers subscribing to new WM content made available from someone (like RCS), running a BuildingBlock IT store, powered by Automation Manager downloading buildingblocks and importing them… Now there’s an idea! :)

For now, go look at page 16 of the release notes for the exact commandline syntax until we get the WM Commandline Reference updated accordingly with the new stuff. Also be sure to check the type reference on page 18.


Automatic agent cleanup

agentcleanupAnother item that is handled better in SR2 is the list of WM agents. It stands to reason that in non-persistent VDI environment, you would end up with a boatload of inactive agents as your hypervisor is generating new computernames, depending on your agent identification method.  Prior to SR2 you would have to clean these out yourself on a regular basis. This is no longer necessary as the Settings tab for the agents now has a setting for automatic agent removal. Besides having it turned off, you can choose between 45, 60, 90 and 120 days where you haven’t heard from an agent and it’ll automagically be removed.

Loads of new registry settings

regedit-supericonThe new Workspace Manager SR2 includes about 9 new behinds-the-scenes registry treaks. There are several settings relating to the WM Relay servers. to configure custom certificates to secure the communications between agents and as well as handling log cleanup and connection timeout. You can check out the tweaks in the updated WM Registry Guide available here.


New filehash based whitelisting.

filehash1Whfilehash2en authorizing files in Workspace Manager security, you can now add SHA-1 filehashes to the authorization. In the past the Appsense guys were moaning on about how that was a big differentiator to their advantage, so there – another FUDbomb defused. Besides, their filehash was afaik MD5 based, which generally is considered inferior to SHA-1, due to a lower bitlength and fewer rotations. Stones and glasshouses, lads. Note that the SHA-1 filehashes can either be imported via the Authorized Files node, or on the new log screen. I’m guessing there might be a new new logtype in the database as a result, so perhaps we soon might see an update of Patrik G’s DB Cleanup Tool. One important thing to mention is that you can also batch import the SHA-1 filehashes with a command line, like this: Pwrtech.exe /importhashes=<file> /createifnotexists.


XenApp 7.x Publishing

ctxreceiverWhat’s there to say; it just works. While some of us were banging around with the SR1 update pack for a while which had a few snafu’s, they to have been ironed out nicely in the SR2 release. One weird thing I’ve come across a couple of times is that for no apparent reason, you may get the WM ‘The application cannot be started”-popup on the XA box, however it seems that a de-publish/republish via QuickEdit resolves that and the problem doesn’t come back. One thing to note, it looks like Citrix brought back Session Lingering in XA 7.6, so while Workspace Manager SR2 offers a surrogate solution via a reghack, it looks like it’s only relevant up to XA 7.5


The above is a small sample of all the improvements that SR2 offers, which I found interesting at this point. There’s plenty more. Again, I cannot emphasize this too mch: When there is a new major release or update to any of the RES products, always take the time to read the release notes. There are loads of goodies in there!


Updated WM Registry Guide

iabtFrom the About-Damn-Time Dept. One of the most popular articles on RG is the Registry reference for RES Workspace Manager. Unfortunately it’s been sitting on the backburner for a while, but no more! As of this weeks release of Workspace Manager 2014 FR2, the guide has been updated with all published registry settings available from the base 2014 release notes and up to. If you come across missing or any other spooky settings, feel free to contribute in the comments section on the article.

doc-icon2<<< Click to view the WM Registry Guide.


Free RES Consultancy

Is your company a RES Software customer? Are you considering if you are getting enough out of your investment? Want to make sure you’re doing it right, and the products have been implemented as they should to suit your business needs? Have a great use-case but not sure how to best go about it?

Why not take advantage of the 15 years of RES experience through RCS and find out how you can extract even more value out of you RES software purchase. RESguru Consulting offers:

  • wbRES Environment health check
  • Tune-up / Optimizations sessions
  • Best practice audits and advisory
  • Design Q&A whiteboarding sessions
  • Technical Workshops

Reach out today to RESguru Consulting Services for a free 3-4 hour online consultation with no strings attached. Until December 31st 2014, RCS is running a global campaign for new and current RES customers. Only requirement is that you currently own RES licenses. No Software Assurance? Not a problem.

Call +1 610 462 2200 or contact m.ranzau@resguru.com to schedule your free consultation.


New Technote: Webservices & Automation Manager

Animated, Gears, boxFrom the Technotes-R-Us Dep: Today I have the pleasure of sharing a new article based on some preliminary work I did for a couple of clients who are looking to integrate SOAP based web-services into RES Workspace Manager. I put together a simple demo that show how to use SOAP calls to pull a live weather report from major airport cities around the world. If you can make that work, you can do pretty much anything from configuring a firewall, set up infrastructure or even process creditcard payments.

This is the first of a two-part article, where we next time will look at wrapping a service around the module and learning a few nifty tricks on how to deal with value dependent dropdowns.

doc-icon2<<< Click here to read part one

doc-icon2<<< Click here to read part two

Automated XenDesktop 7.5 Build with RES AM

By Max Ranzau


From the BuildingBlock Dept. You may recall a couple of years ago that I published a RES Automation Manager buildingblock for Citrix Xen Desktop 5.5, XA and PVS.  Today it’s my pleasure to publish a new buildingblock that will do the same for Xen Desktop 7.5. It’s pretty slick, as it hardly needs any configuration or special prerequisites and allows you to choose all the install options for Xen Desktop.

mr-jMy friend and co-blogger Mr. Jeroen Speetjens from the Netherlands has been kind to share this with the RES community. You folks over at Citrix might also want to take note of this work. In order to use this buildingblock, all you need is the Xen Desktop ISO and a fresh Server 2008 or 2012. Deploy a RES Automation Manager agent to the target server, then import and schedule the module. The module contained in this RES Automation Manager buildingblock will configure everything else you need.

res_am_fileshareWhen you import the buildingblock, you will be prompted for the path to the contens of the XD .iso file, as shown on the screenshot below It is recommended to either mount it somewhere and share it, or copy all the files out of the ISO to a share. Either way, it’s about 2GB and you don’t want to add that as a AM resource, not that Automation Manager can’t handle it, it’s just a hassle next time you’re updating the binaries when you have a new .iso.

XD75_01When you schedule the module to the target server, the module will prompt you for what kind of installation you want. After that it’s off to the races: The average deployment time is about 10 minutes on a target system with SSD’s.

Note: If you decide to download this AM buildingblock and take it for a spin, I kindly ask you to take a moment to comment your feedback below and send thanks to Jeroen for his efforts.

Click the brick as per usual to download the buildingblock:  legobrick-cropped

Remember: RESguru.com is still the number one place to get noticed if you are doing cool stuff with RES: If you’ve got something to share – the guru community cares!

Updated: DB Cleanup Tool 2.0

By Max Ranzau


From the Tools-R-Us Dept. You may recall a while back in February, I reported on a cool utility to address the issue with clearing individual log files in RES Workspace Manager. There’s now a new version 2.0 out from one of our community heroes (=someone who contributes and shares stuff), Patrick van Grinsven in the Netherlands (For the record, Morgan Freeman did not develop it ;). The SQL Database Logging Cleanup Tool has seen a few GUI changes and some other improvements:

  • It is now possible to directly Analyze / Query / Clear the configured logging database if the supplied connection details and logs are valid.
  • It is now possible to Analyze / Query / Clear the logging between dates, or to completely clear the selected log (1)
  • Logging analysis is being sorted descending.
  • Displayed record count added (2)

If you are a RES engineer or admin, this utility should most definitely be in your Bat-utility belt.

For further information and downloads, see the updated article here: doc-icon2


Understanding Automation Manager traffic

By Max Ranzau


BandwidthexampleFrom the Nuts, Bolts and Bandwidth Dept. As some of you noticed, a while back RES released the Reference Architecture document for Automation Manager, so now we have one for both the core products, great. If you have no idea what I’m talking about, go read the document here. The reference doc leads in with the basic deployment scenarios and similar things, but the nittygritty stuff is on page 22+23, where we get down to the actual traffic load numbers. Some of these numbers are obviously based on estimates: For example the resulting network traffic of any job, invariably would be linked to what’s in the job in terms of modules, tasks and resources. Note: The ref.architecture doc specifies packet numbers, but since we are interested in the overall bandwidth consumption I’m leaving those number out as they’d only muddle the picture.

One more thing before we get started. The numbers listed below are obviously without Automation Manager bandwidth management involved. I may do another piece on that particular topic in the future so you get a better idea of what it actually does…

AM Agent-to-Dispatcher idle-traffic.

To begin with, lets talk about idle traffic. It’s a fact of life that all components in a network chat. The question is how much, how often and what the impact would be on the fringes on your infrastructure. Given the numbers below, chances are that you can work out the impact by yourself. While RES is keeping the formula on how to calculate the precise idle traffic under NDA, it’s pretty easy to make a couple of observations off the provided numbers. According to the examples in the document:

When idle, one AM agent spews about 47.5kByte worth of traffic per 5 min/300 sec. That’s not a whole lot as it boils down to just below 160 bytes/sec per agent.

Let’s expand on that: Even if you had 3000 agents on the same site, your total background noise from the AM agents, across all switches would be around 475k/sec. This is next to nothing on a regular LAN. Remember this is the agent-to-dispatcher poll traffic, so it would never have to cross a WAN link when you place your dispatchers strategically on your external sub-nets.

AM Dispatcher-to-Datastore idle traffic.

As most of you know, an AM Agent is wired never to talk to a datastore directly, but always go by way of at least one dispatcher.  How many dispatchers you will need depends entirely on the shape of the infrastructure you want to deploy AM in. Since each Dispatcher+ can handle 1500 concurrent agent connections, you are obviously going to have a lot less dispatchers than agents, however the kicker is that the dispatchers will usually be crossing WAN links if you have them. If you go about your dispatcher layout smartly, you should not need more than one dispatcher per wan, link which makes the following math rather easy. When the dispatchers aren’t doing anything job related, the idle traffic depends on:

A) Are there agents connected?

  • If no, the base impact is about 616k over 300 sec †1), being around 2kB/sec per dispatcher, which is negligible on most WAN links.
  • If yes, it seems there is a slight overhead when an agent is connected (22kB over 5 min = 73 bytes/sec). Presuming that number scales linear, then even with a fully loaded dispatcher with 1500 attached agents, you would be looking at around 110kb/sec dispatcher-to-datastore traffic †2)

†1)Disclaimer: As RES is keeping the formula for calculating this under wraps with the NDA stuff, I’m going to have to make a couple of leaps of faith here. Unless somebody with WireShark and the necessary time on their hands is prepared to run the numbers and verify (or spill the beans in the comments section ;)  – we can only go by what is stated in the doc. The reference document said the Agent idle traffic was measured over a 5 minute interval, but it doesn’t say so for the corresponding dispatcher traffic, thus we are going to presume they used the same measurement interval for that test. †2)The other presumption I had to make, is that each additional agent connected to a dispatcher adds on average the 73 bytes/sec onto the idle dispatcher-to-datastore traffic.

B) The other item to briefly consider: Is the dispatcher a garbage collector? This role has a very low impact and not much is posted about it anywhere at present, other than it’s selected dynamically amongst the dispatchers – supposedly similar to Citrix Zone Data Collectors as they all know about each other through their datastore. What the purpose of the RES AM data collection precisely is, when it happens, what the election criteria is, are still unanswered questions, but hopefully someone will provide that information in the near future. Anyway, based on the released numbers, we may presume the garbage collection role adds approximately 215k/5min to an idle agent, equivalent to just under 780 bytes/sec for the garbage collecting dispatcher. So unless part of your infrastructure is running over a 2G cell data connection you can probably ignore this completely.

AM Dispatcher-to-Datastore traffic, running a job

Since you hopefully won’t have your new Automation Manager installation sitting idly too much, it’s also worthwhile knowing what kind of traffic patterns you are looking at when a job is actually processing. Again we have to do a bit of guestimating based on the provided numbers in the RES reference architecture guide. The numbers are based on a job that downloads a 5.5MB AM resource. The only thing they really tell us is, that regardless if you are master caching or connecting a dispatcher directly to the datastore, the amount of data going across the wire seems roughly equivalent to the size of the resource payload + 500kB. If a dispatcher is set up as a master caching dispatcher, the transfer overhead looks to be about 200kB less than for a regular dispatcher connected to the datastore.

In conclusion, while the overhead isn’t very large, it is not easy to create usable rules of thumb out of this, as the reference document only provides one datapoint (5,5MB and resulting traffic), so in order to make an accurate estimate on traffic size, one would have to know how/if the 500kb overhead grows with the size of the resource/modules. I would suggest this would be an excellent addition to a revision of this document.

Other than that, clarifying comments are welcome!

Fixing IE cookie trouble with RES WM

By Max Ranzau


delcookiesFrom the Worlds Greatest Browser (Right…) Dept: In Internet Explorer 10 and up, the WebCacheV01.dat file was introduced. This file lives in %LocalAppdata%\Microsoft\Windows\WebCache. The webcache folder is hidden. The issue at hand is that the webcache file is always in use, which makes for a rainy day if you try to roam/copy IE cookies, or otherwise store them with RES User-Settings. The issue was described back in April by Rob Beekmans on his blog here.

As of now, the problem is rumored to have been addressed by Microsoft on Server 2012, but is still very much alive and kicking on Server 2008, which at the time of writing still represents a large contingent of server deployments out there.

While Mr. Beekmans illustrated the issue, my partner-in-crime the good Mr. Aarts tackled the issue head on, providing a neat and shareable solution with the RES community in the shape of a Workspace Manager buildingblock. By running a couple of strategic Powershell scripts in the users session and including a couple of extra (freeware) utilities as custom resources, the buildingblock solves the problem described above. The Workspace Manager BB includes the following:

  • A PowerShell command to set the PS execution policy to unrestricted to make sure we don’t get any unnecessary prompts when running the following items unattended:
  • A PS script running at logoff, which backs up the current webcache to a location of your choice *1). The script will create two backup .zip files for the two folders WebCache and INetCookies as well. The script will also leave 5 rotated backup file sets.
  • A PS script running at logon to restore the latest backup of these two folders to their original location
  • Both logon/logoff scripts closes all open file handles before making the backup/restore operations.
  • 7zip and SysInternals Handle64.exe are included as RESWM custom resources.

As you may infer, the above essentially extends the WM User Settings with a basic Hybrid Profile - style copyout-copyin script system. This is necessary, as UserSetting would face the same issue as any other UEM; that the target files are locked. I’d say there’s a loud and clear feature request waiting to be implemented here that could solve a lot of potential headaches for customers.

script1Important: As you can see on the screenshot, there is a couple of places you may need to modify the logon/logoff scripts. The destination where the backup files are to be stored defaults to H:\ – you may need to change that. If you already are using a UNC path like \\server\share\%username% for your User Settings, you perhaps want to consider using that as well. Just remember to add a subfolder for this, like \\server\share\%username%\IEbackup or similar. We could of course have added an environment variable so you only had to change the storage destination once, however it’s two edits. Chances are you may survive it :)

Click the brick to download the buildingblock: legobrick-cropped

Automated VDI Optimization

By Max Ranzau


kcaoFrom the BuildingBlock Dept. Here’s a set of buildingblocks for Automation Manager I’d like to share with you. They have kindly been provided by my co-blogger Rob Aarts. Rob asked me to go through the buildingblock and we agreed to document the result in an article. This collection of modules is very useful when implementing best practices for a Windows 8.1 golden pattern/image. Most of the changes below are already documented online ad nauseum in numerous articles across the net, so I will give you a overview of what optimizations are included in this package. The module collection have the following capabilities:

Default profile registry settings: Configures a few recommended registry settings in .DEFAULT user – check this module out as it gives you a nifty way of actually implementing HKCU settings via Automation Manager.

Run the disk cleanup wizard: This gets rid of the temporary files, offline webpages and all that other gunk that would otherwise waste space for no reason in your workload image.

Explorer tweaks: This is a hodgepodge for HKLM based explorer settings to further simplify the workload. You may want to go through this module as it’s not everything in there which may be of relevance for your own implementation. This particular module include:

  • Set registry permissions for SYSTEM on CSIDL {F02C1A0D-BE21-4350-88B0-7367FC96EF3C} (google it, but in short it’s necessary for some of the following tweaks)
  • Remove Network node from explorer tree
  • Remove unwanted personal folders (My videos, My Music and Desktop) for both x64 and x86 based workloads.

Other tweaks: This module is a collection of commands also based on best practices, to disable/enable Windows settings, which in turn further optimizes the VDI workload’s startup time and general performance. The module includes the following:

  • Disable NTFS last access timestamps (slows things down when enabled)
  • Disable Boot logo+log and hibernation
  • Enable windows remote management (we all want that!)
  • Remove the pesky Modern/Metro Win8.1 apps (refer to this technet article on what’s going on)
  • Remove the Fax device (as we for once don’t want the users to go fax themselves… :)

vdi-regRegistry optimizations: More machine based registry settings to either remove general annoyances, speed things up, etc. There are 13 optimizations included in this module: Disable boot optimization, TCP/IP large send offload, system restore, memory dumps, new network dialog, and clearing of pagefile on shutdown. The module also increases disk I/O timeout and service startup timeouts and much more.

vdi-tasksScheduled tasks: As we all know there are loads of things that happen behind our backs in a windows session. Keeping these to a minimum in a workload will keep everyone happy. This module disables 31 different background subsystems. Examples are Windows Defender (yes, it’s nice but it has no business in a workload), System restore, Bluetooth monitoring, several CEIP items (Customer Experience Improvement Programs) and much more.

vdi-svcsServices: The last module in the optimization pack disables 61 Windows services which according to best practices are deemed unnecessary in a VDI workload. There are 3 services which are left untouched (i.e. defined, but not being disabled) by this module per default: Device Setup Manager, Function Discovery Provider Host, Windows Search and Windows Store (if disabled, Windows store-based apps do not work) I will leave it to your own discretion to determine if these 4 additional services are right to disable in your own scenario.

Closing notes: In general I recommend that you breeze through the modules for items that you may want to keep running as these modules together completely strips the workload down to the bare metal for maximum performance yield.

Click the brick to download:  legobrick-cropped