Blog | Page 29

Retrieving Event Log Entries from Remote Computers

By Scott | Published: February 23, 2015

One of the functions that BatchPatch provides is the ability to retrieve information from many target computers, simultaneously. And one of the most common sources of information that systems administrators need to access is the event log. So, the question then is how does one use BatchPatch to obtain event log information from remote computers? See below.

First, make sure the ‘Remote Registry’ service on the target computer is enabled and running. If it’s not already running, you can use BatchPatch to start it. The two commands that you would need to run are:

WMIC SERVICE where (displayname='Remote Registry') CALL ChangeStartMode Manual

WMIC SERVICE where (displayname='Remote Registry') CALL startservice

If you’re not familiar with using BatchPatch to remotely execute commands, please see this link for instructions. You can use the two commands listed above, in conjunction with the instructions at the following link, to enable and start the Remote Registry service on your target computers:
Executing Remote Commands With BatchPatch
Once you have the ‘Remote Registry’ service running on the target computers in question, you’re ready to retrieve event log information. Highlight your host(s) in the grid, and then select ‘Actions > Get information > Get event log entries > Settings/filters’.
In the ‘Event Log Filters’ window, choose the desired settings. Note, the more logs we search, the longer the process will take, so it’s a good idea to search only as far back as you need to. You can optionally include or exclude particular types of events or specific event IDs. Once the desired filters are applied, click OK. For this example I am searching a max of 1000 entries over the past 24 hours.
Now that the desired filters are set, let’s retrieve matching entries from the System log on the target computer(s). Highlight the host(s) and select ‘Actions > Get information > Get event log entries > System’. If you want to retrieve contents of the Application log or the Security log, you would simply choose the appropriate menu item. However, in this example I’m interested in retrieving only entries in the System log.
That’s pretty much all there is to it! Wait for a moment until the query returns, and then you’ll be able to examine the entries that were found.

Posted in Blog, General, Tutorials | Tagged event log, event logs | Comments closed

Using the Task Scheduler in BatchPatch

By Scott | Published: February 17, 2015

BatchPatch really shines when it comes to providing real-time control and monitoring of the Windows Update process, reboots, software deployments, and remote script execution on numerous computers. But what if you want to execute tasks while you’re sleeping? For sysadmins it’s extremely common to have to perform tasks on servers at off-hours, often in the middle of the night. We’re all used to staying up through the middle of the night to perform various maintenance routines, but there are plenty of times we’d rather be lying in bed and letting our computers perform scheduled tasks for us! Needless to say, scheduled tasks are absolutely *not* appropriate for every situation. Many times a task is too critical to be executed without human oversight, but in the cases where something is less critical, why not let BatchPatch handle it for you in the middle of the night?

For example, let’s say that you have some servers that aren’t super-critical, but they still get used a lot and can’t be easily taken down during the day. Perhaps on these servers it’s safe for you to schedule an update + reboot in the middle of the night? Obviously that is your decision to make, and you always have to be prepared for something to go wrong. However, assuming you’ve decided that you want to run updates/reboots in the middle of the night, here’s how you can do it with BatchPatch.

Highlight your hosts in the BatchPatch grid, and then select ‘Actions > Task scheduler > Create/modify scheduled task.’ You’ll see the Task Scheduler appear.
In the drop-down menu, select the task that you want to perform. For the sake of this example, we’re going to use “Download and install updates + reboot if required.” However, you can choose any BatchPatch task, including any of the custom commands or scripts that you’ve previously created. After selecting the desired task, set the run time, and then click OK.
We can see that there is a task and time applied to each row that we had previously selected, but we’re not quite done. The task scheduler is disabled by default. So, even though we setup task actions and run times, we have to enable the scheduler in order for our tasks to be submitted for execution at the desired times. To enable the scheduler, click on the small clock/timer icon in the upper right corner of the BatchPatch window. The icon will turn from red to green, indicating that the scheduler has been enabled.
Note, you can set the scheduler to be always-on, if you want, so that you don’t have to manually enable it. Go to ‘Tools > Settings > General’ and select the checkbox to ‘Enable Task Scheduler on startup.’
That’s all there is to it. The scheduled tasks will run at the designated times. What if you want to receive an email of the grid activity? We agree that it would be convenient to wake up in the morning and check your email to see how things went. In this case, one option is to create an additional row in the grid with a new task that will be responsible for emailing you an HTML report of the grid status at some point after you expect your tasks to be complete. In this example I’ve created an email notification task to run 2 hours after my updates/reboots.
The email notification that we created in the previous step will be sent according to the settings defined in ‘Tools > Settings > Email notifications.’ However, I want to make one adjustment in my email notification task, so that the notification sends me an entire grid report instead of just a single row report. Select ‘Actions > Email notifications > Override default email notification.’ Then type “$grid” in the ‘Body’ field. This tells BatchPatch to email me a whole grid report when this task is executed.
The final grid, ready to run tasks tonight, looks like the screen below.

Posted in Blog, General, Tutorials | Tagged scheduled tasks, Windows Updates | Comments closed

Sequencing Updates and Reboots Across Multiple Target Hosts

By Scott | Published: February 10, 2015

One of the questions we get sometimes is how do you update and reboot a set of computers in a specific sequence, without having to babysit the entire process?

In the most recent version of BatchPatch we introduced the ‘Basic Multi-Row Queue Sequence.’ This new feature takes the existing job queue to the next level by allowing you to string together job queues from multiple rows in the BatchPatch grid all into a single, larger multi-row (multi-host) job queue.

In the next version of BatchPatch, expected to be released in early Spring 2015, we will be introducing the ‘Advanced Multi-Row Queue Sequence.’ This feature will improve upon the basic sequence by allowing more complex configurations. Instead of limiting you to sequences that process one host at at time in a specified order, the advanced sequence functionality will enable you to process multiple hosts in sequence, such that you could have X number of hosts perform any actions, and when they complete their actions, another set of Y number of hosts can be triggered to perform actions, and when they complete their actions, another Z number of hosts can be triggered to perform actions, and so on.

For a detailed tutorial on using the ‘Basic Multi-Row Queue Sequence’ please follow this link: Using the Basic Multi-Row Queue Sequence

For a detailed tutorial on using the ‘Advanced Multi-Row Queue Sequence’ please follow this link: Using the Advanced Multi-Row Queue Sequence

Posted in Blog, General, Tutorials | Tagged reboot, sequence, update | Comments closed

Uninstalling Java Remotely from Numerous Computers

By Scott | Published: January 28, 2015

One task that nearly every administrator has to complete at some point or another is the removal of Java. As with many typical sysadmin tasks, removing software on remote computers is very quick and simple with BatchPatch. Today I’d like to show you how to remove Java from many computers using BatchPatch. We have a few different options for executing the uninstallation, so take a look through all options before deciding which one you want to use. IMPORTANT: Always test a destructive process like this on a non-production machine before you attempt to perform an action on one or many production machines!

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

First we need to locate the UninstallString value in the registry for the version of Java 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 Java 8 Update 31, and it contains the following data:
MsiExec.exe /I{26A24AE4-039D-4CA4-87B4-2F83218031F0}
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 Java that you are uninstalling:
MsiExec.exe /qn /X{26A24AE4-039D-4CA4-87B4-2F83218031F0} /norestart
Click the ‘Execute’ button
In the ‘All Messages’ column we see exit code 0, which indicates success.

IMPORTANT NOTE:

Methods 2 and 3 should be used with caution. Both of the following uninstallation methods utilize the Win32_Product class. However, before proceeding with either method, please review this article to learn why some sysadmins are opposed to using the Win32_Product class.

Method 2: Uninstall a specific Java version, by name query:

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, substituting the version of Java that you want to remove. Make sure that the name you use matches the exact name that appears in the ‘Add/Remove Programs’ wizard on the target computer(s):
wmic product where (name = 'Java 8 Update 31') call uninstall
Click the ‘Execute’ button
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.

Method 3: Uninstall all versions of Java, by name query

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

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 'Java%') call uninstall
Click the ‘Execute’ button
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 ‘Java’ is removed. The reason we see a return code of 1605 for the ‘Java Auto Updater’ is because the Java uninstallation was executed first, and the Java Auto Updater was removed as part of the Java uninstallation. WMIC didn’t know that, of course, so when it tried to remove ‘Java Auto Updater,’ it returned 1605, because ‘Java Auto Update’ was already removed. 1605 translates to ERROR_UNKNOWN_PRODUCT - This action is only valid for products that are currently installed.

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

BatchPatch Ports

By Scott | Published: January 21, 2015

Remote connections in BatchPatch are established using a combination of WMI (Windows Management Instrumentation), SMB (Server Message Block) and PsExec. Additionally ICMP (Internet Control Message Protocol) is used for pinging. BatchPatch also needs access to the target computer’s administrative shares: ADMIN$ and IPC$.

In order for PsExec and SMB to work properly…
If you are using Windows Firewall on the target computer, then generally the only thing you need to do is create an exception for “File and Printer sharing.” More details on configuring Windows Firewall can be found here: Using BatchPatch with Windows Firewall. However, if you are *not* using Windows Firewall and instead are using some other firewall, then you would need to explicitly permit traffic to the target computer from the BatchPatch computer on the following ports in order for SMB and PsExec to function properly:

UDP 137
UDP 138
UDP 445
TCP 135
TCP 137
TCP 139
TCP 445

As a test, after you configure the firewall you should try to connect from the BatchPatch computer to the target computer’s ADMIN$ share, which you can do by going to ‘Start > Run’ on the BatchPatch computer, and then type “\\targetComputer\ADMIN$” without the quotes. The ADMIN$ share doesn’t need to be explicitly enabled unless you have previously disabled it through group policy or registry changes.

In order for WMI and ICMP to work properly…
The target computer must be able to receive and process RPC (Remote Procedure Call) requests. Both the WMI and RPC services must be running on the target computer. If you’re using Windows Firewall on the target computer, then please follow the instructions on this page to configure it properly: Using BatchPatch with Windows Firewall. On that page you will be instructed to enable ‘File and Printer Sharing’ along with ‘Windows Management Instrumentation (WMI)’ or ‘Remote Administration’ depending on the target operating system.

To test WMI try executing ‘Get last boot time’ in BatchPatch. If you see an RPC error, then your firewall still needs additional adjustment. If you see an ‘Access Denied’ error, make sure that the account you are using to run BatchPatch (or the account that you specified in the ‘Alternate credentials’ dialog for the target) has local administrator privileges on the target. If you continue to see ‘Access Denied’ have a look at this page.

Additionally, test ICMP by pinging the target computer from the BatchPatch computer. Normally an ICMP exception shouldn’t need to be explicitly enabled in the Windows firewall because it will be included implicitly as part of the ‘Remote Administration’ exception noted above. However, if you find that WMI is working successfully but pinging is still not working, consider enabling ICMP explicitly in the Windows firewall configuration.

WMI and hardware/network firewalls

If there is a hardware firewall involved in addition to or instead of the Windows firewall, the configuration for WMI can potentially be a bit trickier, depending on the particular firewall device. WMI connections, by default, are not established on a static/fixed port. Instead WMI uses dynamic port configuration for its connections, which means that the actual ports used for a given connection are established on-the-fly at the time of connection. Each connection will end up using different ports. In the context of a classic hardware firewall, this used to be a problem because hardware firewalls would typically require any open ports to be configured manually. An enterprise firewall administrator could never know in advance which ports would need to be opened. However, fortunately many modern firewalls now implement DCE/RPC, which solves this problem and allows the use of dynamic ports for WMI/RPC. If you have a network level hardware firewall in place between the BatchPatch computer and the target computers, you’ll need to configure it to allow DCE/RPC, so that it can open the necessary ports, on-the-fly, for each WMI connection. More info on DCE/RPC can be found at the following two links:

https://en.wikipedia.org/wiki/DCE/RPC
http://wiki.wireshark.org/DCE/RPC

If DCE/RPC is not an option, it’s also possible to configure WMI to operate over a single port: WMI Static Port configuration

Posted in Blog, General, Tutorials | Tagged Firewall, port, Ports, psexec, wmi | Comments closed

BatchPatch Tips and Shortcuts

By Scott | Published: January 15, 2015

Diplaying cell contents: The quickest and simplest way to view the content of any particular cell in a BatchPatch grid is to middle-click on the cell. The middle-click button is the same as the scroll-wheel on most mouses. If you didn’t already know, the wheel is also a button that can be clicked/pushed just like a regular left or right mouse button. Middle-click a cell to quickly view its contents.

Moving the cell contents tooltip/window: After you display the cell contents with middle-click, sometimes you might want or need to move the tooltip that is displayed to a new location. You can do this by right-clicking anywhere on that tooltip/window. Then just drag it to the desired location.

Expanding row contents: You can double-click on any row in the grid to display the entire row’s contents in an HTML formatted window. If you want to view the contents of more than one row at a time, then simply highlight the rows and press the ‘R’ key on your keyboard. Alternatively you may right-click on the selected rows and then click the option to ‘Expand row(s)’

Moving rows up/down in the grid: You might not have realized that you can move individual rows or groups of rows up and down in the grid without sorting the entire grid. Highlight the rows you want to move and then hold down the CTRL key and press the + or – key to move the rows up or down.

Adding/removing buttons on the ToolStrip/ToolBar: Select ‘Tools > Customize visible toolstrip buttons’, and then check or uncheck the items you want to add or remove. If you ever want or need to reset the ToolStrip back to its default configuration, you can do that by selecting ‘Tools > Reset toolstrip to default configuration.’

Re-arranging icons/buttons on the ToolStrip/ToolBar: Hold down the ALT key, and then select the button you want move with left-click. Drag it to a new location on the ToolStrip and it will stay there. If you ever want or need to reset the ToolStrip back to its default configuration, you can do that by selecting ‘Tools > Reset toolstrip to default configuration.’

Toggling the grid border style: Pressing CTRL-B will toggle through the 4 possible grid border style options. You can have no cell borders, horizontal borders only, vertical borders only, or both horizontal and vertical borders, which is the default configuration.

Modifying the row selection color: If you don’t like the default yellow row selection color, make it any color you want. Select ‘Tools > Row selection color’ or simply click on the color palette icon in the menu strip. You’ll be presented with a new window where you can either select one of the out-of-box colors or set your own color by clicking on the color palette.

Changing the intensity of the alternating row background color: There is a tiny little arrow icon in the lower-left corner of the BatchPatch window. Clicking this icon reveals a slider that lets you change the intensity of the gray row background color for alternating rows in the grid. You can disable it altogether by dragging the slider to the lowest possible position.

Transparency: Yes, it’s true that BatchPatch supports transparency, if you so desire. This is one of those features that we included for fun, simply because we could (not because we think it’s useful). 🙂 In the lower-right corner of the BatchPatch window there is a tiny arrow icon. If you click on this icon a slider will appear. Lower the slider if you want to make the BatchPatch window transparent.

LED images: The column that appears farthest to the left in the BatchPatch grid contains ‘LED’ images to indicate online/offline status of computers in the grid. While these LED images will change color when a row is rebooted or pinged, did you know that you can also control these images independently of what actions are executed for a given row? For example, if you load a list of hosts into a grid, you can simply left-click on the LED image row header to start (or stop) an online/offline check for all hosts in the grid. Furthermore, if you middle-click the LED image row header, all LED images in the grid will be reset to gray. Middle-clicking the LED image of a specific row will disable that particular row from being included in the online/offline status check. Shift-middle-clicking a specific row’s LED image will turn that image blue, which can be used to indicate ‘completion’ if you desire.

Importing hosts: Did you know that when importing computer names or IP addresses into the BatchPatch grid, you can simultaneously import MAC addresses and/or general notes? For example, when you select ‘File > Add Hosts’ you aren’t limited to just adding a list of computer names (EDIT 20150602: new/additional import options are available and explained here: Importing Hosts and Other Information Into a BatchPatch Grid) . If you want to add a MAC address with each computer, you can do so by formatting your list as follows:

host1#1C6F65D56413 host2#2D:5E:43:F2:21:24

If you want to populate the ‘Notes’ column for a given host, then you can use the following syntax:

host4|notes for host4 host5|notes for host5

If you want to populate both MAC and Notes for your hosts, then use this syntax:

host1#1C6F65D56413 host2#2D:5E:43:F2:21:24 host3#1B3A65B54322|notes for host3 host4|notes for host4

Note, you can also create a text file using the above syntax, and then simply drag and drop the .txt file onto the BatchPatch window, or use ‘File > Open’ from within BatchPatch to browse to the .txt file.

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

Remotely Deploy a Standalone .MSU Update to Multiple Computers

By Scott | Published: January 8, 2015

You need to install a single .MSU update on many computers, but you don’t want to log on to each computer to initiate a manual installation, and you don’t want to deal with writing a script. I know how you feel. I’ve been there many times. The good news is that with BatchPatch you can take care of the entire process with just a few clicks and a couple of minutes. Here’s how it works…

In the example below we will remotely install update KB2965142 using a standalone .msu file obtained from Microsoft.

In the BatchPatch grid, highlight the computers that you will be deploying the update to. In the screenshot below you’ll see that I’m only deploying the update to a single target computer. However, if you are working with many target computers you can simply highlight all of them instead of just one. All other steps are identical.
With the host(s) selected, let’s now create the deployment by clicking ‘Actions > Deploy > Create/modify deployment.’ In the deployment window we’ll select the .msu file from our computer, and then we’ll select the ‘ install’ radio button as well as the ‘/norestart’ checkbox since I don’t want the target computer to restart on its own. We can optionally also give this deployment a title so that it can be saved for later use. In this example I’ve used the title ‘Install KB2965142.’ To save it simply click the >> button, which will add it to the list of ‘Saved Deployments.’

Once the deployment is created we can either execute it immediately for the highlighted rows by clicking the “Execute now” button, or we can close the deployment window and execute it later directly from the Actions menu. In this case let’s close the window so that you can see how it works when you save a deployment before executing it. After closing the deployment window, simply highlight the hosts, right click or use the actions menu, and select ‘Deploy > Execute saved deployment > Install KB2965142.’ We can see that as soon as the ‘Install KB2965142’ is selected, a tooltip appears showing us that particular saved deployment’s configuration. The configuration is, of course, the same configuration that we applied in the previous step before we saved the deployment.
We are now presented with a confirmation dialog, which gives us another opportunity to verify the configuration of the deployment that we are about to execute. Click ‘OK’ to begin execution.
When the installation completes we get exit code 3010, which indicates that the installation was successful but a reboot is required to complete it. We can use BatchPatch to initiate the reboot at our convenience.

Posted in Blog, General, Tutorials | Tagged deploy .msu, remote deployment | Comments closed

Determine if a Particular Windows Update is Installed on Remote Computers

By Scott | Published: December 29, 2014

Windows administrators periodically need to check their systems to determine if a particular update has been installed. BatchPatch provides a simple way to scan for previously installed Windows Updates on numerous remote computers. You can use this facility to generate a consolidated report of the computers that have a particular update installed, or you can generate a report of all installed updates on all computers. It’s up to you.

Note, we have an alternate method for checking if a particular update is installed posted here: An Alternate Way To Check If Computers Have A Particular Windows Update Installed

Add hosts to a grid in BatchPatch, and then highlight the desired hosts and right-click > Windows Updates > Generate consolidated report of update history. This will bring up the report settings window. Since the purpose of this tutorial is to search for a particular update, let’s examine our options for doing this.

One option is we can use the “Filter by title:” section to specify which update we are looking for. Perhaps we need to find computers with KB2800095 installed. All we have to do is enter that particular ID into the ‘Filter by title’ field before we execute the search. In the screenshot below you can see I’ve set the search preferences to only include the last 300 days, and I’ve entered ‘2800095’ into the ‘Include’ section of the filter options. When I execute the search I expect to get a list of machines that had this update installed within the past 300 days.

Click ‘Generate Report’ to begin the search process. When the search completes, we can see both of the machines that we searched had this update installed in the past 300 days.

Pretty simple, right? The other option we have for obtaining this information is very similar, but in this case we would leave the ‘Filter by title:’ section blank. In this case we’ll simply retrieve all updates that have been installed on the selected computers during the past 300 days. Once we have this complete list, we can then do a search for the particular update in question, or we can sort by update title. As you can see in the screenshot below, I simply typed ‘2800095’ into the “Find” field, and the first computer with that update installed was highlighted. Continually clicking the ‘Find’ button will rotate through every search hit, as you would expect.

That’s all there is to it. I told you it was simple!

Posted in Blog, General, Tutorials | Tagged windows updates history, windows updates report | Comments closed

Multi-Step Execution Using the Job Queue

By Scott | Published: December 18, 2014

Last week we published an update to the BatchPatch Job Queue that adds some nice new features, and I thought I’d take some time to show you what you can do with it.

In the new Job Queue interface you’ll find the following items that weren’t previously available:

Wait for host to go offline and come back online:
In previous versions of BatchPatch if you executed a task that involved rebooting a computer, you didn’t have a way to start the next task in the queue as soon as the computer finished rebooting. Instead you’d have to set a “wait” period of something like 10 minutes, after which the next task would begin, regardless of whether or not the computer had actually finished rebooting.

However, in the new Job Queue you now have the option to Wait for host to go offline and come back online. If you insert this special item after a reboot task, BatchPatch will automatically keep track of the target computer’s status, waiting for the machine to go offline and then come back online before proceeding with the next task. The next task will not begin until BatchPatch is able to confirm that the target computer is replying to pings *and* also responding to Windows Management Instrumentation (WMI) queries. If a ping is successful but the machine isn’t ready to respond to WMI queries, BatchPatch will wait a minute before it tries again. As soon as it gets a valid response from WMI, it will proceed with the next task in the queue.

Note, there is an additional setting in the Job Queue that allows you to set the timeout threshold for this feature. See ‘Wait for host to go offline / come online’ global timeout (minutes). The default value is set to 60 minutes. If the host never goes offline (maybe it hangs while it’s shutting down) or if the host goes offline but never comes back online and/or never begins responding to WMI queries within the 60 minute window, BatchPatch will simply stop processing the job queue for that host.

Stop queue execution if previous action fails/errors

Inserting this new special item in a queue after a custom script gives you the ability to make sure that BatchPatch will not proceed with the queue execution if the custom script does not run successfully. When this Stop queue execution if previous action fails/errors item is reached in the queue, BatchPatch will check the previous action’s exit code. If the previous action’s exit code is non-zero, BatchPatch will terminate the queue.

Saved User-Defined Commands and Deployments

The new Job Queue interface now lets you add your own saved commands and deployments to a queue. We know that a lot of you have been waiting for this, and we’re pleased that it’s finally available for you.

Saved Queues

You can finally save your job queues for future execution! This is another item that many of you have been waiting for. The cool thing is that once you save a queue, it will then appear “hard-coded” into the BatchPatch actions menu for future execution. You can execute a saved queue by highlighting hosts in the grid and then selecting Actions > Job Queue > Execute saved job queues. See the screenshot below:

Posted in Blog, General | Tagged job queue, multi-step execution | Comments closed

Remotely Installing .NET 4.5.1 on Windows 7 and Windows Server 2008R2

By Scott | Published: December 8, 2014

This is an example of using BatchPatch to install .NET 4.5.1 remotely on Windows 7 and Windows 2008R2 computers.

Overview: The process is very straightforward. Add the target hosts to your BatchPatch grid, create the BatchPatch deployment, and then finally execute the deployment. It’s important to always test a new deployment on a single machine before you try to execute it across numerous computers. This way you can iron out any kinks in the process to make sure it’s working properly before you move forward with it on your entire network.

Important: Please try to remember that any remote deployment task in BatchPatch requires that the installation be executed silently / quietly. When I say “silent” or “quiet” installation, I mean that the installation process needs to be executed without requiring any user interaction whatsoever. As you know, many installer packages will prompt the logged on user to click OK or to select an installation directory or to specify some other installation-specific options. However, in the case of a remote installation, there won’t be any opportunity to click on various options that the installer presents. In fact, if the installer presents any options, the presentation of these options will actually be hidden from the view of any logged on users because it’s being executed in the background. In this case the installation will simply appear to hang indefinitely without ever completing. So, any time you’ve attempted a deployment and it appears to be hanging with no completion, then you can rest assured knowing that it’s simply waiting for user input. In that case, since the remote deployment is hidden from view, you would have to manually kill the installation process on the target computer and then start over again with the correct silent/quiet parameters.

Determine the “silent” / “quiet” installation parameter:
You can generally learn what the “silent” / “quiet” parameters are by executing the installation at the command line with the “/?” or “/help” parameter. For example, take a look at the screenshots below, where I have launched the .NET installer package with the “/?” parameter. Doing so displays a windows with all of the installation options.
Create the deployment:
Highlight the host(s) and choose Actions > Deployment > Create/modify deployment. In the window that appears, you’ll select the location of the .NET installer file, and you’ll add the “/q” parameter to ensure that the installation executes without any interaction. In the screenshot below you can see I’ve also added the /log parameter, so that I can review the installation log in the event of a problem or failure. Note: The installation package that I’m using is the offline installer that Microsoft offers. You will not be able to use their online installer for this silent deployment because their online installer does not offer a silent/quiet installation parameter. The offline installer is available here: http://www.microsoft.com/en-us/download/details.aspx?id=40779
I’ve saved the Deployment, and now I can execute it using Actions > Deployments > Execute saved deployment

Confirm the deployment configuration and click OK on the prompt that appears:

.NET Installer Exit Codes:
0: Installation completed successfully.
1602: The user canceled installation.
1603: A fatal error occurred during installation.
1641: A restart is required to complete the installation. This message indicates success.
3010: A restart is required to complete the installation. This message indicates success.
5100: The user’s computer does not meet system requirements.

Posted in Blog, General, Tutorials | Tagged deploy .NET, deployment, install .NET, Remote Installation | Comments closed