Tuesday 13 September 2011

WSUS Offline Update – Installing Windows updates without an Internet connection and WSUS

This was orignally post by Maik Koster . Thanks to him for such a wonderful post.

Today I would like to share one of the handiest tools for servicing Windows systems, if they can’t be updated via WSUS or online at Microsoft Update, or if you for any reason want to install the updates from a CD/DVD/USB or even a share.

It’s called WSUS Offline Update (formerly known as c’t offline Update), created and maintained by Torsten Wittrock. It’s main purpose is to download all critical and security related Updates to a local folder and execute the required ones on a system, without the necessity to be connected to the internet or a working WSUS Server.

It supports Updates for Windows XP, Windows Vista, Windows 7, Server 2003, Server 2003 R2, Server 2008 and Server 2008 R2 both in32 and 64 bit (where applicable), Office 2003, Office 2007 and Office 2010. One can select the required languages, in- or exclude ServicePacks, .Net Frameworks, C++ Runtime libraries, Windows Defenders definitions, Microsoft Security Essentials and so on. Updates can come either from Microsoft Update directly or also from your WSUS Server.

Once downloaded, one can create ISO images per product and language or per language only. Or copy a subset of selectable updates on a USB Stick. Then a second component can be called from each individual computer that shall be updated, either locally or over the network. This will then evaluate the current computer against the available updates and install all missing ones plus a bunch of additional items like Internet Explorer, PowerShell, Windows Defender, .Net Frameworks, etc.
OK, let’s have a quick look on how to do that

Getting the Updates

First, download the most recent version from WSUS Offline Update (http://download.wsusoffline.net/). Be sure to unblock the file and then extract the content to a folder. Can be locally or on a network share. If you place it on a share, be sure to map it with a Drive letter.
Now you want to get the updates and optionally create the Update medias. To do so, start the “UpdateGenerator.exe” from the just extracted folder.

SNAGHTML4770c56

As you can see, there are plenty of options what to download and to create. All downloads will be stored in some subfolders at the location, where you started the application from. So be sure to have some space available. We will go over some of the more important ones a bit later. Also be sure to start the download regularly to always have the latest updates available.

Now if you have selected all the products you would like to download updates for, click on “Start” and the download process will start. It will first get a list of all available updates and then just download the ones that haven’t been downloaded already. Depending on your selection and bandwidth, this can take quite some time.

SNAGHTML47b32d9

It will also check for superseded Updates, mark and optionally remove them. It’s also maintaining a list of excluded Updates which can be tweaked to your own needs. See the FAQs in the “doc” folder for more information.

SNAGHTML47ecc0c

Updating a Client

After the Updates have been downloaded, you an use the created CD/DVD/USB media to update a computer. Optionally it’s also possible to call it over the network, even if that’s not the preferred method and contradicts a bit with the idea of an “Offline” Update Winking smile. However to do so, just share the Client subfolder and make sure that you map this share with a drive letter on the computer, as the scripts don’t work with a UNC path. Now execute the “UpdateInstaller.exe”. Preferably with Administrative privileges.

SNAGHTML59feb93

The GUI will let you choose only available options. So it might differ depending what you downloaded or have made available on your media and the OS and installed components itself. Interesting to mention here is, that you can tell it to automatically reboot and recall itself as often as required by the Update process. As a side note, the automatic reboot doesn’t work, if you started the process over the network as the temporary account, created for the automatic logon, doesn’t have the appropriate drive mapped. Well, this is the out-of-the-box behavior and as most of the commands are just scripts, it is possible to tweak this to your needs if you really need to have this option available.
However, to start the process, simply click on the “Start” button again and let the magic happen. Just be aware, that it might take some time.

SNAGHTML5a64ff1

Automation

The whole project has been published under the GNU/GPL and most of its components are vb scripts, batch files or AutoIt scripts. It’s possible to exclude specific Updates, include additional ones, etc. Please see the FAQ (located in the “doc” folder) for some more information on this.
Interesting part here is, that you can also automate the process to keep your medias up to date. In the “cmd” folder you will find a bunch of command line scripts, that you can use for this purpose. E.g. to update your media after each Microsoft Patchday, just create a batch that calls the “DownloadUpdates.cmd” and "CreateISOImage.cmd” (or “CopyToTarget.cmd” for a USB Stick) with the appropriate parameters and schedule it to run on the required dates. Also the execution on the client can be automated as well by either calling the “Update.cmd” file from the root of your media or the “DoUpdate.cmd” from the “cmd” folder. Actually the first one just calls the latter one and as you can see in the screenshot above, also the GUI just calls them with selected parameters.

It is a real benefit to always have a USB Stick available, filled with the latest Updates and ready to execute on any machine whenever needed. Or how about automatically updating your Reference image(s) offline with the latest updates? I will show you how, in the next Blog post 

Cheers!!!!!!!!!

Tuesday 6 September 2011

Package is not getting updated on Distribution point.

Imagine the scenario where you find yourself waiting longer then usual for a package to reach a Distribution Point. You have tried a refresh, a removal and every other possible action within the Configmgr Console GUI. Yet, the package never reaches and remains in the "Install Pending" state. Here are 3 nifty logs found in the SMS installation path that will help save you some drops of blood and empower you to find out the problem fast.

DESPOOL.LOG
DISTMGR.LOG
SCHEDULE.LOG

If you see the following entry in the DESPOOL.LOG, the following steps may be able to address your problem.
Received package AAA9999A version 4 SMS_DESPOOLER 9/15/2010 10:11:46 AM 6024 (0x1788)

There is already a newer version of the compressed package for package AAA9999A, discard this one. SMS_DESPOOLER 9/15/2010 10:11:46 AM 6024 (0x1788)

However, when you look at the path and also in the package status, you see that it is not there, and still pending. The above message effectively tells Configmgr there is no need to send the package down since there is a newer one. But this is not true, therefore here is a quick work-around.

It's time to put aside the GUI and go straight to the raw locations of these packages and IDs. It is important to note that prior to attempting this steps, please ensure that the packages are not distributed to the affected distribution point by verifying for example through the GUI.
  1. Go to your SMS installation drive of the affected Distribution Point and open up the following folders:
    • SMSPKG
    • SMSPKGSIG
    • SMSSIG$
    • SMS\inboxes\distmgr.box
    • SMS\inboxes\pkginfo.box
  2. Search for the packageID in each of the locations and delete them. These will consist of various file extensions i.e. AAA9999A.PKG, .ICO, .NAL, .PCK, .TAR and possibly some deltas as well (i.e. AAA9999A.DLT_x.rf$ etc...). As usual, please exercise caution whenever you do a delete to make sure you know what you are deleting. Check that no sources of the PackageID resides anymore with another search.
  3. Send the package back down again to the Distribution Point through the console.
  4. Monitor the above 3 logs to see the magic flow. My favourite method is to use Trace32.exe to highlight the PackageID string so that you see it zooming its statuses fast and furious when things start to tinker together. After some time, you should see your packages arrive!

Friday 2 September 2011

ConfigMgr (SCCM) – New Site to Site data replication flow in SMS 2003 and ConfigMgr 2007 explained

Thanks for Excellent write up on replication process of ConfigMgr in details from Terry McKinney and to Anoop for sharing this  :)

=====
image

NOTE: Question marks (???) in the text below indicate random character generation by SMSExcec thread processing.
SMSExec thread component on source site initiates replication request
SMSExecutive thread component that is requesting data replication places the data to be replicated in replmgr.box\outbound\low OR replmgr.box\outbound\normal OR replmgr.box\outbound\ high folder. Low (3), normal (2), and high (1) specify replication priority requested by the SMSExec thread that requests replication.

Replmgr:
Replication Manager (ReplMgr) scans the three folders listed above for incoming data. Replmgr prepares the job source files by combining data files destined for replication to a given site in the \replmgr.box\process\<destinationsitecode>_<priority> folder (i.e., XYZ_2). If there are no pending replication requests to a given site that have the same replication priority, Replmgr implements steps A and B listed below. It there are pending replication requests to that site that have the same replication priority that are already scheduled for replication, data for new request(s) is held in the Replmgr.box\process\<destinationsitecode>_<priority> folder. Data for the new request(s) will remain in the Replmgr.box\process\<destinationsitecode>_<priority> folder until the pending same-priority request completes data replication OR the new replication request(s) reaches 6 hours in age. At this time, Replmgr will implement steps A and B listed below. If a replication job of the same priority and destination site is still pending, ReplMgr implements steps A and B below to create an additional same-priority replication request for that site.
A. Data to be replicated is moved to \replmgr.box\ready\<priority>_??????.<destinationsitecode> (i.e., 2_SKEJFS.XYZ).  This folder is referenced in log files as the "transfer root".
B. ReplMgr then creates a .JOB file in the \Schedule.box folder.

Scheduler:
At the top of the Scheduler process loop (except on service startup) Scheduler activates any pending jobs by completing the following steps:
A. Compresses all files in the transfer root (i.e., \replmgr.box\ready\2_SKEJFS.XYZ) into a single package file and writes this file to \schedule.box\tosend\<job id>.P??.
B. Creates a destination site despooler instruction file in \schedule.box\tosend\<job id>.I?? to be transmitted immediately after the package file created in step A is transmitted.
C. Creates a send request in the \schedule.box\requests folder (<priority>_???<originatingsite>.SRQ) (i.e., 2_5ZKABC.SRQ).
D. Determines if the package and instruction file needs to be routed through an intermediate child site. If so, a routing instruction file is created (RT??????.INS) for the send request.
E. Schedules the send request by moving it into an appropriate sender outbox. Each installed sender type creates its own folder under schedule.box\outboxes. The most common sender outbox is schedule.box\outboxes\LAN.

Sender:
1. Sender transmits the package file and then the instruction file to the remote site by completing the following steps:
A. Renames the send request (<priority>_???<originatingsite>.SRQ) to (<priority>_???<originatingsite>.SRS (changes the filename extension to .SRS)
B. Transmits the package (\schedule.box\tosend\<jobid>.P??) file to the remote site Despoolr.box\receive folder (the SMS_SITE share) and renames it to <sendrequestid>.PCK
C. Transmits the accompanying instruction file (\schedule.box\tosend\<job id>.I??) to the same location and renames it to <sendrequestid>.INS
D. Flags the <priority>_???<originatingsite>.SRS file with a "sending complete" flag.
E. Creates a \schedule.box\<sendrequestid>.DWS (done with sending) file.
Replication component processing at the destination site Despoolr.box\receive folder)

Despoolr:
The Despooler process first checks the signature on the replicated files. If signed correctly, despoolr decompresses the instruction file and implements the instructions contained within that file – to decompress the package into the \replmgr.box\incoming folder in this case.
ReplMgr:

Replication Manager analyzes incoming files and replicates the objects to appropriate inbox folders. The appropriate inbox folder is specified by the component on the source site server that began the replication process. Inbound replication jobs that use transactions must bear a transaction ID that is greater than the existing number for that object type that is contained in the sitecode.trs present on the destination site. If this condition is met, the transaction is considered valid and the inbound replication objects are passed to the destination component/inbox. If this condition is not met, the transaction is considered invalid and the replication objects are discarded by Replication Manager.
Post - replication cleanup on originating site:

Scheduler:
A. Updates the corresponding job status to "complete" when it finds the \<sendrequestid>.DWS during its
processing cycle.
B. Performs cleanup - deletes the related package and instruction files in the \schedule.box\tosend folder
C. Deletes the transfer root folder (i.e., replmgr\ready\2_SKEJFS.XYZ)
D. Marks the send request for deletion

ReplMgr:
After the transfer root has been deleted, pending replication requests with the same priority and destination site that are less than 6 hours in age can be created. Note that if there are existing jobs of the same priority and with the same destination site that are older than 6 hours, ReplMgr will request scheduling an additional replication job of the same priority for replication to that site.

Scheduler:
A. Deletes completed send requests when it finds the associated <job_id>.dws file for that job during its processing cycle.
B. Deletes the completed job files (minimum cycle: once per hour, maximum cycle: once per process loop).