Downloading Windows Updates for Distribution to Offline Computers on High-Security Networks

For environments with high-security networks that not only have NO access to the internet or a WSUS but also disallow copying any data from the high-security network to any other lower-security network, BatchPatch has a feature for pre-downloading some or all of the Windows Updates security updates repository from Microsoft on a computer that has internet access, so that the repository can be transferred to the high-security offline network, where updates can then be distributed to computers. This process can be performed without ever having to remove any files/data from the secure network. Files are only ever transferred from the low-security network to the high-security network.

Note, BatchPatch offers multiple methods for deploying security updates to offline computers. For more on the various ways you can use ‘cached mode’ and ‘offline mode’ please see: Cached Mode and Offline Updates

  1. Enable cached mode first in order to activate the required menu item that will be used in the next step. Go to ‘Tools > Settings > Windows Update’ and then tick the ‘Enable cached mode’ checkbox near the bottom.
    2016-06-16 13_25_29-Cached-mode
  2. Now select ‘Tools > Download offline updates repository’
    2016-06-16 13_54_38-Tools-Download-offline-updates-repository
  3. Select the products for which you would like to download updates, and select at least one language preference, and then click OK.
    2016-06-16 13_27_43-Download-offline-updates-repository
    The WsusScn2.cab file will be downloaded from Microsoft and then parsed and filtered based on your selections.
    2016-06-16 13_40_26-parsing
  4. A list of Urls for the products that you selected will be displayed in a new window. At this point you can optionally delete rows for any updates that you are not interested in downloading. Click “Download files to local cache” when you’re ready to begin the download process.
    2016-06-16 13_27_44-Download-offline-updates-repository
  5. A new window will appear where you can monitor and control the download process.
    2016-06-16 13_51_05-Download-progress
  6. Now that you have downloaded all the updates, the next step is to move the populated cache directory to a computer on the high-security offline network. Please use whatever method is appropriate for your environment in order to transfer the files from the online network to the offline network, such as a USB drive.
  7. At this point the setup process is complete. You should have a folder full of update files on a computer that is attached to the offline network. BatchPatch should be launched with cached mode and offline mode enabled. The local update cache directory specified in Tools > Settings > Windows Update must point to the directory that contains all of the update files that you just moved. You may now proceed to update your computers. Highlight your hosts in the grid and select Actions > Windows Updates > Download and install updates + reboot if required. The target computers will now all “download” their updates from the BatchPatch computer’s local cache. I use quotation marks around “download” because what actually happens is the BatchPatch computer copies the appropriate update files to the target computers. The target computers then add these files to their Windows Update cache, and then the updates are installed.
  8. I have included a series of screenshots below to show the whole the process. Upon completion we have the overall content logged to the ‘All Messages’ column, with detailed information in the ‘Local Agent’ and ‘Remote Agent’ logs.

    The computer that is running BatchPatch will copy the most recently published WsusScn2.cab offline scan file that was downloaded in an earlier step to the target host.
    BPCopyingWsusScn2ToTarget

    BatchPatch instructs the target host to perform a search for available updates against the WsusScn2.cab file, which is why the target host does not require internet access to perform its search.
    BPSearching

    The list of available updates on the target host is copied back to the BatchPatch console. Since the updates were all previously downloaded to BatchPatch’s local cache directory, BatchPatch proceeds to copy the required updates to the target host.
    BPCopying

    After the updates have been copied to the target host, the target host must move the files to its Windows Update cache.
    BPCaching

    When the caching process completes, the installation is finally ready to be executed.
    BPInstalling

    After installation, the target host is rebooted and the process is complete.
    BatchPatchOfflineModeDownloadInstallRebootAllMessagesLog
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Remote Software Deployment Hangs Indefinitely – How to Resolve

One of the most common support questions we receive from customers is regarding software deployments that appear to never complete. In these situations, the remote software deployments seem to just hang forever until you eventually kill the task. Why does this happen? How do you prevent it?

It’s important to understand that remote software deployments must be executed silently/quietly on target computers. Essentially what this means is that when the deployment runs, it must not attempt to display any notifications, confirmations, or configuration dialogs.

Normally if you install software on your local computer by double-clicking on the application’s setup.exe, it pops up a dialog box that requires you to click ‘Next’ a few times before the software installation is completed. You might also be prompted to choose an installation path or some other settings and configurations for the software that is to be installed. Well, as you can imagine, if you execute a software deployment remotely, but the deployment pops up an installation configuration screen on the target computer, you won’t be able to respond to that dialog because you won’t see it appear. Not only will it not appear on the local machine that you’re using to execute the remote deployment, but it also will not appear on the target computer either. This is because the remote deployment process runs on the target computer hidden, with no visible user interface. Any confirmation dialogs or settings dialogs that are displayed by the setup package will simply never be seen. The result is that the software installation appears to hang forever without completing. This is because it’s waiting for user input, but since the dialog is hidden, no user can or will ever be able to provide the input and click ‘Next’ to complete the remote installation.

The solution is very simple, but it does require an extra step for the administrator. In order to prevent the deployment from hanging, it must be executed without ever requiring any user interaction, so that it can run to completion in a hidden remote process. Virtually all software installation packages come with a facility to run a ‘silent’ or ‘quiet’ installation. When the installation package is executed, the administrator simply needs to include the appropriate argument/parameter/switch that tells the package to execute silently/quietly.

In many cases, the silent/quiet installation parameter is simply a /S or /s or /Q or /q. However, often times the silent/quiet switch is something different, so unfortunately you cannot make any assumptions about which switch to use. In the case of the Java deployment that you see in the screenshot below, the silent parameter is simply /s.

2016-06-13 14_00_29-Settings

The real question, however, is how does one determine what switch/parameter to use to execute a silent/hidden deployment? I wrote a longer, more detailed posting last year that explains exactly how to go about figuring out what the silent/quiet installation parameter is for any given software deployment.

Understanding and Discovering The Silent Parameters Required to Remotely Deploy Software with BatchPatch

We also have many specific tutorials for deploying software remotely posted at the following link. You’ll find tutorials for deploying applications like Adobe Flash, Adobe AIR, Adobe Reader, 7-Zip, Skype, Firefox, Chrome etc:

Software Deployment with BatchPatch

Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Triggering ConfigMgr (SCCM) Client Actions Remotely

As a convenience for those of you are using SCCM in your environment, last year we added the ability to trigger SCCM client actions remotely, directly from BatchPatch. We’ve received a few questions about this topic recently, so I figured I would take a few minutes to provide some context here.

SCCM administrators sometimes need or want to initiate a certain activity on client computers at non-scheduled times. For example, maybe you need your clients to perform a ‘Software Inventory,’ and you would like to execute that action on-demand. You could certainly establish a remote connection to all of the computers in question, and then you could execute a command line task to trigger the desired process. Or you could fire up PsExec from your workstation, and then use it to remotely trigger the process on a set of target computers. However, if you are a BatchPatch user, you can initiate the process directly from BatchPatch in a single click. BatchPatch isn’t doing any special magic here. We’re simply making it quicker/easier for you to remotely trigger SCCM client actions without having to mess with any command line copy/paste.

The list of SCCM triggers available in BatchPatch are:

{00000000-0000-0000-0000-000000000001} Hardware Inventory
{00000000-0000-0000-0000-000000000002} Software Inventory
{00000000-0000-0000-0000-000000000003} Discovery Inventory
{00000000-0000-0000-0000-000000000010} File Collection
{00000000-0000-0000-0000-000000000011} IDMIF Collection
{00000000-0000-0000-0000-000000000012} Client Machine Authentication
{00000000-0000-0000-0000-000000000021} Request Machine Assignments
{00000000-0000-0000-0000-000000000022} Evaluate Machine Policies
{00000000-0000-0000-0000-000000000023} Refresh Default MP Task
{00000000-0000-0000-0000-000000000024} LS (Location Service) Refresh Locations Task
{00000000-0000-0000-0000-000000000025} LS (Location Service) Timeout Refresh Task
{00000000-0000-0000-0000-000000000026} Policy Agent Request Assignment (User)
{00000000-0000-0000-0000-000000000027} Policy Agent Evaluate Assignment (User)
{00000000-0000-0000-0000-000000000031} Software Metering Generating Usage Report
{00000000-0000-0000-0000-000000000032} Source Update Message
{00000000-0000-0000-0000-000000000037} Clearing proxy settings cache
{00000000-0000-0000-0000-000000000040} Machine Policy Agent Cleanup
{00000000-0000-0000-0000-000000000041} User Policy Agent Cleanup
{00000000-0000-0000-0000-000000000042} Policy Agent Validate Machine Policy / Assignment
{00000000-0000-0000-0000-000000000043} Policy Agent Validate User Policy / Assignment
{00000000-0000-0000-0000-000000000051} Retrying/Refreshing certificates in AD on MP
{00000000-0000-0000-0000-000000000061} Peer DP Status reporting
{00000000-0000-0000-0000-000000000062} Peer DP Pending package check schedule
{00000000-0000-0000-0000-000000000063} SUM Updates install schedule
{00000000-0000-0000-0000-000000000071} NAP action
{00000000-0000-0000-0000-000000000101} Hardware Inventory Collection Cycle
{00000000-0000-0000-0000-000000000102} Software Inventory Collection Cycle
{00000000-0000-0000-0000-000000000103} Discovery Data Collection Cycle
{00000000-0000-0000-0000-000000000104} File Collection Cycle
{00000000-0000-0000-0000-000000000105} IDMIF Collection Cycle
{00000000-0000-0000-0000-000000000106} Software Metering Usage Report Cycle
{00000000-0000-0000-0000-000000000107} Windows Installer Source List Update Cycle
{00000000-0000-0000-0000-000000000108} Software Updates Assignments Evaluation Cycle
{00000000-0000-0000-0000-000000000109} Branch Distribution Point Maintenance Task
{00000000-0000-0000-0000-000000000110} DCM policy
{00000000-0000-0000-0000-000000000111} Send Unsent State Message
{00000000-0000-0000-0000-000000000112} State System policy cache cleanout
{00000000-0000-0000-0000-000000000113} Scan by Update Source
{00000000-0000-0000-0000-000000000114} Update Store Policy
{00000000-0000-0000-0000-000000000115} State system policy bulk send high
{00000000-0000-0000-0000-000000000116} State system policy bulk send low
{00000000-0000-0000-0000-000000000120} AMT Status Check Policy
{00000000-0000-0000-0000-000000000121} Application manager policy action
{00000000-0000-0000-0000-000000000122} Application manager user policy action
{00000000-0000-0000-0000-000000000123} Application manager global evaluation action
{00000000-0000-0000-0000-000000000131} Power management start summarizer
{00000000-0000-0000-0000-000000000221} Endpoint deployment reevaluate
{00000000-0000-0000-0000-000000000222} Endpoint AM policy reevaluate
{00000000-0000-0000-0000-000000000223} External event detection

In BatchPatch you can see all of the triggers listed alphabetically under ‘Tools > SCCM client triggers.’

To execute a particular task, simply highlight the desired target computers in the grid, then select ‘Tools > SCCM client triggers’ and choose the desired task. In the screenshot below you can see that when I hover over a particular task, it shows the actual command that will be executed on the target host.

SCCM-client-triggers-BatchPatch

Posted in Blog, General, Tutorials | Tagged | Comments closed

Deploying 7-Zip 16.0.2

Today I’ll demonstrate how to deploy the latest version of 7-Zip (version 16.0.2) to multiple target computers simultaneously.

  1. Start by obtaining the installation media. I downloaded the 64-bit installer from http://www.7-zip.org/download.html
  2. Configure the BatchPatch deployment. Highlight the desired target hosts in the grid, and then select ‘Actions > Deployment / Create/modify deployment’. In the Deployment form configure the deployment as I have done in the screenshot below. You need to provide a title, select the path of the installer that you downloaded in the previous step, and most importantly add the /S switch to the optional ‘Parameters’ field. The /S switch is what the 7-Zip installer uses to execute a silent/quiet installation. This means that when you use the /S, no interaction from the user will be required to complete the installation. This is a requirement for any/all remote installations. Without the /S, your deployment will hang indefinitely. More on understanding silent/quiet parameters at the bottom of this page. You can see the completed deployment configuration in the screenshot below:
    2016-05-23 17_46_18-Deploy .msi .msp .msu .exe .reg .vbs .bat .cmd .ps1 etc
  3. With the deployment form properly configured, you’re ready to execute the deployment on the target hosts that you have selected in the grid. Either click ‘Execute now’ in the deployment form, or if you prefer you may first save the deployment and then execute it later directly from ‘Actions > Deployment > Execute saved deployment > 7-Zip 16.0.2 x64’
  4. Confirm the deployment to be executed. Click OK on the dialog that appears to confirm the action.
    2016-05-23 17_49_02-new 1 - BatchPatch X2
  5. When the action completes a few seconds later, you’ll see ‘Exit Code: 0 (SUCCESS) to indicate that everything is finished.
    2016-05-23 17_50_48-new 1 - BatchPatch X2

IMPORTANT: In order to execute a remote installation with BatchPatch, you must first determine the proper command line switch/parameter to initiate a “silent” or “quiet” installation.

A proper silent/quiet installation will complete without any user interaction, but if you execute an installation without specifying the correct silent/quiet parameter, the hidden remote process will hang indefinitely without ever completing.

Different installation packages have different command line switches. The silent/quiet switch might be any one of the following, or something completely different, depending on how the installer was created: /S, /s, -S, -s, /silent, -silent, /Q, /q, -Q, -q, /quiet, -quiet.

More here:
Understanding and Discovering the Silent Parameters Required to Remotely Deploy Software with BatchPatch

Posted in Blog, General, Tutorials | Tagged , , | Comments closed

Update + Reboot Cycle – Create a Continuous Loop to Download and Install Windows Update Plus Reboot Until there are no Applicable Updates

EDIT 20200924: The long deprecated ‘Update + Reboot Cycle’ has finally officially been removed. It was really just a limited version of the BatchPatch Job Queue, so please now use the BatchPatch Job Queue instead, which will enable you ton produce the same functionality with many more customization options. Tutorial: Update + Reboot Cycle – Create a Continuous Loop to Download and Install Windows Update Plus Reboot Until there are no Applicable Updates
—————————————-

When it comes to Windows Update, one thing that can be pretty frustrating is that after you install a set of Windows Updates on a given computer, occasionally you need to repeat the download/install/reboot process a second time in order to get *all* applicable updates installed. When all goes smoothly, the administrator download and installs updates on a computer and then reboots the computer. That’s it. If another check for available updates is performed, there are no applicable updates left to install. However, in some cases after you install all the applicable updates and reboot the computer, a subsequent check for updates reveals that there are now more/new updates available to that computer. For those sysadmins who are performing the entire process manually without the help of an application like BatchPatch, the amount of work is doubled, and the time required to perform monthly server maintenance is increased dramatically.

BatchPatch has always provided a feature to easily handle multiple update + reboot cycles, but we’ve never blogged about it before. Considering that we still regularly receive emails about this topic, I thought it would be a good time to describe how you can use BatchPatch to perform a continuous cycle to make sure that *all* applicable updates are installed, even if it requires multiple iterations of download/install/reboot.

In BatchPatch take a look under ‘Actions > Windows Updates > Update + reboot cycle > Modify default cycle settings.’ The “Update + Reboot Cycle” in BatchPatch is essentially a dedicated Job Queue.
2016-05-16 16_42_05-Update + Reboot Cycle Settings  (these settings are saved and apply to ALL rows)

A BatchPatch job queue enables you to execute a sequence of actions on a given target host or set of hosts. That sequence might, for example, instruct target computers to download/install/reboot then wait until reboot is complete before performing the same download/install/reboot a second time (or more times, if desired). For a tutorial on using the job queue, please see this link: Using the Job Queue in BatchPatch for Multi-Step Execution

Since the ‘Update + Reboot Cycle’ task is one that administrators routinely ask for, we also include a dedicated Job Queue just for that purpose. There is nothing different about the ‘Update + Reboot Cycle’ dedicated job queue as compared to a regular/custom job queue that you create in the ‘Create/modify job queue’ window, with the exception that it’s a dedicated resource for this purpose. There is only one global ‘Update + Reboot Cycle’ queue. You can modify it by selecting ‘Actions > Windows Updates > Update + Reboot Cycle > Modify default cycle settings.’ The default update + reboot cycle queue is:

Download and install updates + reboot always
Wait for host to go offline and come back online
Download and install updates + reboot if required

This cycle works well for most users’ needs, but of course you are welcomed to modify it, if needed. Or if you prefer you may always just create a custom job queue instead. When you’re ready to execute it, simply highlight the desired target hosts in the grid, and then select ‘Actions > Windows Updates > Update + reboot cycle > Execute cycle.’
2016-05-16 17_02_24-
2016-05-16 17_02_41-new 1 - BatchPatch X10

Posted in Blog, General, Tutorials | Tagged , , | Comments closed

Executing Processes on Computers that are Frequently Powered Off or Disconnected from the Network

Every administrator at one time or another has the need to update user computers that are rarely connected to the corporate network. Whether you need to install Windows Updates or update a third-party software product, it’s always a pain in the butt when the computer in question is a laptop that is rarely brought in to the office and put on the network.

BatchPatch makes this process as easy as possible because we provide an option in the Task Scheduler that enables the administrator to execute a custom process on a computer only after it first detects that the computer is connected to the network and powered on. The task option is titled ‘Run task immediately upon detecting target computer online.’ With this option you are able to schedule a particular task, such as ‘Download and install Windows Updates + Reboot if Required’ on a particular computer. BatchPatch will then check once per minute to see if that computer is online and responding to requests. If the computer responds, then BatchPatch will begin the task. If not, then BatchPatch will sleep for a minute before trying again. This process can be left to run indefinitely until it is complete.

  1. Highlight the desired host(s) in the BatchPatch grid, and then select ‘Actions > Task scheduler > Create/modify scheduled task.’
    2016-05-02 16_52_35-Photos
  2. Select the desired task from the ‘Task’ drop-down menu, and then check the box that says ‘Run task immediately upon detecting target computer online.’ Then click the OK button. The task does not have to be a built-in BatchPatch task. It can also be any custom script, process, or command that you have previously created inside of BatchPatch.
    2016-05-02 16_54_32-new 1 - BatchPatch X3
  3. Lastly, enable the scheduler if it is not already running. To do this, click on the small clock icon in the upper right corner of the BatchPatch window. When it has been enabled it will be green (rather than red), and if you mouse over it you see a tooltip that says ‘Scheduler Enabled.’
    2016-05-02 17_03_26-

  4. That’s all there is to it. At this point you can sit back and wait for the task to complete, or better yet you can go on about your daily work. Simply check back on the status in BatchPatch at any time. If you’d like to take it one step further and configure an email alert to notify you when the task has been completed, this is also pretty simple. In this case you would create a job queue with two tasks in it. The first task would be your desired action, such as ‘Download and Install Windows Updates + Reboot if Required.’ The second task in the queue would be the email notification task. Then once you have saved this job queue, you can run it via the scheduler, using the same option that you used above to ‘Run task immediately upon detecting target computer online.’ This way, when the task completes you’ll get an email notification to let you know. More on email notifications can be found here: How to send email notifications in BatchPatch
Posted in Blog, General, Tutorials | Tagged , | Comments closed

Uninstall QuickTime Remotely

By now most of you are probably aware that Apple is no longer going to be supporting or updating QuickTime for Windows: https://support.apple.com/kb/DL837?locale=en_US

The internet is abuzz with recommendations to remove QuickTime unless you know that you absolutely need it. If you’re not sure, you probably do *not* need it. Many of you are now focused on how to get it off of your user computers, so here’s a tutorial to remotely remove QuickTime from many computers using BatchPatch.

IMPORTANT: As always, please make sure to test any potentially destructive process or script on one computer before running that process or script on numerous computers!

Method 1 (Preferred Method): Uninstall a specific QuickTime version, by UninstallString:

    This method provides more precision since it uses the exact uninstall string for the application instead of a name search. However, it also requires a bit more effort.

  1. First we need to locate the UninstallString value in the registry for the version of QuickTime that we want to remove. Generally one of the following two registry keys will contain the UninstallString value that we are looking for:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

    OR

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

    On my test machine I located the UninstallString value for QuickTime 7.79.80.95, and it contains the following data:

    MsiExec.exe /I{FF59BD75-466A-4D5A-AD23-AAD87C5FD44C}

  2. In BatchPatch, highlight the target hosts and select ‘Actions > Execute remote process/command > Create/modify remote command 1’. Enter the following syntax into the command field, substituting the correct string for the particular version of QuickTime that you are uninstalling:
    MsiExec.exe /qn /X{FF59BD75-466A-4D5A-AD23-AAD87C5FD44C} /norestart
  3. Click the ‘Execute’ button
    2016-04-26 13_34_25-new 1 - BatchPatch X1
  4. In the ‘All Messages’ column we see Exit Code 0, which indicates success.
    2016-04-26 13_35_46-Uninstalling QuickTime Remotely from Numerous Computers _ BatchPatch - The Ultimate W


IMPORTANT NOTE:

Method 2 should be used with a bit of caution. The following uninstallation method utilizes the Win32_Product class. However, some sysadmins are opposed to using the Win32_Product class, and they have a good point. Before proceeding with this method, please review this article to learn why some sysadmins are opposed to using the Win32_Product class for software removal.

Method 2: Uninstall all versions of QuickTime, by name query

Method 1 and Method 2 are similar, except we change the query in Method 2 to include all software products on the computer that begin with the name ‘QuickTime’

  1. In BatchPatch, highlight the target hosts and select ‘Actions > Execute remote process/command > Create/modify remote command 3 (logged output)’. Enter the following syntax into the command field:
    wmic product where (name like 'QuickTime%') call uninstall
  2. Click the ‘Execute’ button
    2016-04-26 13_46_27-new 1 - BatchPatch X1
  3. You can see in the screenshot below that this command returns successfully with Exit Code 0. Also, the ‘Remote Command Output Log’ column shows the output that was returned by the target, giving us additional confirmation of what was executed. Note, in this case every app on the computer that has a name beginning with ‘QuickTime’ is removed.
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

Checking for Available Windows Updates on Windows 7 Targets Takes Too Long!

If you’re experiencing *very* slow Windows Updates processing (scanning, downloading, installing) with Windows 7, in particular, you’re not alone.

For approximately a year now Windows 7 users have been struggling with very slow performance during the scan for Windows Updates. The issue occurs regardless of whether you check for updates using BatchPatch or directly on a target computer in the control panel Windows Update GUI.

The problem appears to mostly affect machines with slower CPUs. For example, in our lab here we have an old Dell Netbook with Intel Atom CPU. In the most recent test, it took 18 hours just to check for available updates! And no, that is NOT a typo.

It’s hard to say *exactly* why the process is so slow, but it’s likely a combination of complex rule processing for update revisions, superseded updates, and update expiration, along with inefficiencies in the Windows Update Agent code that causes it to require a lot of CPU time, especially for older/slower CPUs. The following links have some good information on the likely causes:

https://superuser.com/questions/951960/windows-7-sp1-windows-update-stuck-checking-for-updates
https://superuser.com/questions/890038/why-is-checking-windows-update-so-slow

Over the past year Microsoft has released numerous updates to the Windows Update Agent, many of which were intended to address the slowness issue. However, here we are in April 2016, and the slowness is worse, not better. A year ago the same Dell netbook that took 18 hours to scan this month took only a few hours. And while a few hours is definitely NOT good performance by any means, it’s much better than 18 hours! Realistically though, the scan should only take minutes, not hours. Note, there does seem to be a correlation between the number of available updates and the time it takes for the scan to complete. For example, as soon as updates are installed on our lab Dell Netbook, the time it takes to check for updates drops to only a few minutes.

If you’re experiencing this slowness on any of your Windows 7 machines, there might finally be a solution!

The poster, EP, in the comments section on the following blog appears to have found the magic combination of updates required to fix the slowness.

He/she says:
"Install a COMBINATION of the following updates on Win7 SP1 -- KB3138612 AND KB3145739. I found out that patching KB3145739 alone without patching the WU Client for Win7 SP1 is not enough."

http://www.askwoody.com/2016/possible-fix-for-the-abysmally-slow-windows-7-update-scans/comment-page-3/#comment-80655

I can confirm that in our lab environment the machine that last week took 18 hours to scan for updates just now took only 10 minutes after installing both of the updates mentioned above. Also there have been numerous other reports from users around the web that this update combination worked in their environments to dramatically reduce scan times. Let’s just hope that it continues to hold up in the future.

2016-06-14 Update:

As of June 14th, the problem resurfaced, and apparently now you also need to install KB3161664 and possibly also KB3161608 to keep things moving. See https://www.askwoody.com/2016/win7-users-install-kb-3161664-to-speed-up-windows-update-scans/ for more information.

He/she says:
"The Windows Update search/scan 'forever' problem has once again resurfaced for Win7 SP1 as of June 14 (June Patch Tuesday). The KB3153199 Win7 updates are no longer doing the job. And once again a new win32k.sys security update (KB3161664) has been released (MS16-073), which supersedes/replaces KB3153199. Win7 SP1 users should now install KB3161664 to speed up Windows Update scans instead of KB3153199 as of today 6/14."

"It looks like Microsoft has released a more permanent fix to the problem KB3161647 which is part of the KB3161608 Update Rollup of June 2016. If KB3161664 win32k.sys fix is not installed, try installing the KB3161608 update rollup, which updates the WU client."

2016-10-19 Update:

Microsoft has written an article about this topic here:
https://support.microsoft.com/en-us/kb/3200747

Posted in Blog, General, Tutorials | Tagged , | Comments closed

How to Block the Windows 10 Upgrade

As most of already know, Microsoft has been pushing hard in the past few months to get Windows 10 installed on machines that are currently running Windows 7 and 8/8.1. We have received numerous emails from customers asking us how to prevent their computers from installing Windows 10 when using BatchPatch to apply Windows updates.

  • Do not try to “hide” the ‘Upgrade to Windows 10…’ update. This is not sufficient because it will only remain hidden until Microsoft re-releases it and effectively unhides it on your computers. You’d end up in a never-ending game of cat and mouse.
  • Do not try to “exclude” the ‘Upgrade to Windows 10…’ update. This will work, but you will have to exclude it every single time you apply Windows updates to your computers today or in the foreseeable future.

There is only one method that you should consider using to prevent the Windows 10 upgrade from running on your PCs. Microsoft describes in the following link setting two registry values to prevent the Windows 10 upgrade from running on a given computer:

https://support.microsoft.com/en-us/kb/3080351

If you are not using Group Policy to apply these settings in your organization, then you may use BatchPatch to deploy the registry settings to target computers. The process is simple.

  1. First create a the .REG file. In Notepad add the following text and save the file as ‘Block Windows 10 Upgrade.reg’
    Windows Registry Editor Version 5.00
     
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\GWX]
    "DisableGwx"=dword:00000001
     
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
    "DisableOSUpgrade"=dword:00000001

    2016-04-04 14_52_17-Block Windows 10 Upgrade.reg - Notepad

  2. After you have created the ‘Block Windows 10 Upgrade.reg’ the next step is to deploy it to your computers. In BatchPatch highlight the desired target computers, and then select ‘Actions > Deploy > Create/modify deployment’

    2016-04-04 15_23_58-Photos

  3. In the ‘Deployment’ window you’ll use the settings shown in the above screenshot, where the ‘Block Windows 10 Upgrade.reg’ file is the file you’ll be deploying.
  4. After you execute the deployment, the ‘Deployment: Exit Code: 0’ indicates success. The registry values were applied to the target computers, and they will not be accidentally/automatically upgraded to Windows 10.

    2016-04-04 15_18_42-new 1 - BatchPatch X1

Posted in Blog, General, Tutorials | Tagged , | Comments closed

Remotely Deploy EMET 5.5 to Multiple Computers

If you need to deploy EMET (Enhanced Mitigation Experience Toolkit) to one or more computers on your network, you may follow the instructions below.

  1. Download the EMET 5.5 .MSI installer file from Microsoft. At the time of this writing, it’s available from the following link: https://www.microsoft.com/en-us/download/details.aspx?id=50766.
    I’ve saved the .MSI file to

    E:\Temp\EMET\EMET setup.msi

    2016-03-28 17_26_48-EMET

  2. In BatchPatch select the desired target computers that will be receiving the EMET deployment. Then select ‘Actions > Deploy > Create/modify deployment’. In the window that appears you must now select the .MSI file location as well as any other desired settings. For the sake of this EMET deployment, use the settings show in my sample screenshot below.
    2016-03-28 17_30_46-Deploy .msi .msp .msu .exe .reg .vbs .bat .cmd .ps1 etc
  3. At this point we’re already ready to execute the deployment. Simply click the ‘Execute now’ button in the deployment form. Alternatively, you may save the deployment for later execution using the ‘>>’ button.
  4. The deployment generally will not take very long to complete. On my test Windows 2012 target the entire process in BatchPatch took just 23 seconds. In the screenshot below you can see that upon completion BatchPatch printed Deployment: Exit Code: 0 (SUCCESS).
    2016-03-28 17_35_58-
  5. That’s all there is to it. EMET 5.5 has now been deployed to my Windows 2012 machine.
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed