Archive for January 2010

Automatic Updates and Windows Server 2008 Server Core installations.   Leave a comment

Just a quick update to share a script used to install updates that have been downloaded already by the Windows Update client. Thinking about it, it’s a shame that the wuauclt.exe application doesn’t have an /install switch, since it already has the pre and post-requisites of /detectnow and /reportnow respectively. Oh well, the script was simple enough.
 
As an important aside, I wrote this for the WSUS 3 client, since that’s what we have here in our environment. This isn’t an issue for us given it’s destined for use on Server 2008 Core installations, but if you intend to use it elsewhere, just keep that in mind.
 
This is not designed to be a detection script, since you should already have configured your Windows Update settings via Group Policy. It’s purely meant to allow updates to be installed from the command line.
 
To execute the script, copy and save the content below into a JavaScript file (for example, installUpdates.js), then run it from the command line with the following syntax:
cscript //nologo installUpdates.js
 
You will not be able to run this through the wscript host (which is by design). In any case, here’s the code.
 
Cheers,
Lain
 
 
/*
  A simple script written for Server 2008 Server Core installations to install updates that
  have already been downloaded.
*/

var oWSUSSession, oWSUSSearcher, oWSUSUpdates, oWSUSInstaller;
var oUpdates, oUpdate, oInstallResult;

var oError, oDebug = true;  // Switch Debug to false to avoid some of the text output.

try {
  oWSUSSession = WScript.CreateObject("Microsoft.Update.Session");
  oWSUSUpdates = WScript.CreateObject("Microsoft.Update.UpdateColl");
  oWSUSSearcher  = oWSUSSession.CreateUpdateSearcher();
  oWSUSInstaller = oWSUSSession.CreateUpdateInstaller();

  // Perform a search against the WSUS server to see what updates are required.
  oUpdates = oWSUSSearcher.Search("IsInstalled=0 AND Type='Software'");
  if (Debug) WScript.StdOut.WriteLine("Detected updates = "+ oUpdates.Updates.Count);

  if (oDebug) WScript.StdOut.WriteLine("Enumerating search results:");

  for (var i = 0; i < oUpdates.Updates.Count; i++) {
    oUpdate = oUpdates.Updates.Item(i);

    if (Debug) WScript.StdOut.WriteLine("- Downloaded="+ oUpdate.IsDownloaded + "," + oUpdate.Title);

    // We're only interested in updates that are already downloaded.
    if (oUpdate.IsDownloaded) {
      oWSUSUpdates.Add(oUpdate);
    }
  }

  if (Debug) WScript.StdOut.WriteLine();

  // If we have some updates that are classed as downloaded, then it's now time to install them!
  if (oWSUSUpdates.Count > 0) {

    WScript.StdOut.WriteLine("Updates to install = "+ oWSUSUpdates.Count);
    oWSUSInstaller.Updates = oWSUSUpdates;

    // Run the installer
    oInstallResult = oWSUSInstaller.Install();
    WScript.StdOut.WriteLine("Reboot required = "+ oInstallResult.RebootRequired);
  }
} catch(oError) {
  WScript.StdOut.WriteLine(oError.description);
}
Advertisements

Posted January 29, 2010 by Lain Robertson in Server Core, Windows Server 2008 R2

Tagged with , ,

Working with OLSync R4 and Forefront Identity Manager 2010 RC1.   4 comments

Hi All,
This is just a quick and dirty entry illustrating the steps I went through to get the Live@EDU Outlook Live Management Agent (R4 release) to install on Forefront Identity Manager 2010 RC1. I say this is a “dirty” entry because it’s really just a cut and paste from the most recent reply I sent to someone prodding me for more information with the salutations and best wishes taken out for privacy reasons.
The content is not a click-by-click walkthrough, and as I note in the body, it’s not necessarily the perfect manner in which to work around the 64-bit and installation prerequisite caveats. That said, the approach worked for us, and we are now running both products in a production capacity for some 12,500+ student accounts. In fact, I daresay it’s working better than we’d initially expected.
One task I still have to work through, which is worth reiterating here, is to set up another FIM installation to take a look at the option of importing the OLMA directly from within the FIM Synchronisation Manager. Right now, I have no idea where I’m going to find the time, but it is something I will look at if there’s still a point in doing so sometime down the track. The sole incentive for doing so is to avoid the hassle involved with manipulating the original MSI in order to get it to install the OLMA.
Without further ado, the content you’re most likely interested in is pasted below.
Good luck,
Lain

Yes, we’ve successfully provisioned accounts from Active Directory to Live@EDU with FIM2010 RC1 – in fact, we’re using RC1 in production now, and maintain a current user base of 12,500-ish students accounts in Live@EDU, so it’s a reasonable sized environment.

As I included in my post, we are running FIM over two servers:

FIM Server:

  • Windows 2008 R2 64-bit hosted on VMware
  • 12 GB RAM
  • OLSync R4 32-bit (in “AD account only” mode, because we do not yet have Exchange)
  • Four management agents (SQL Server, iPlanet, Active Directory and Outlook Live)
  • Manual configuration of OLMA
  • The portal component of FIM is not installed, so there is no codeless provisioning
FIM back end:
  • Windows Server 2008 R2 32-bit
  • 4 GB RAM
  • SQL Server 2008 with SP1
I’m assuming you already have FIM installed, in which case the only issue you face is installed the Outlook Live Management Agent (OLSync R4). The .msi from the Microsoft Connect site is specifically locked down to 32-bit operating systems, and has four or five prerequisite checks. These two facets stop you from installing OLSync on the FIM server, since the FIM server can only be 64-bit, not 32-bit.

There are two methods for installing the Outlook Live Management Agent:

  1. via the .msi package, or
  2. via the Management Agents section > Actions menu > Import Management Agent… option from within FIM itself.
I used option 1, but I had to alter the .msi from Microsoft to do it. Firstly, I had to change the 32-bit flag within the .msi to 64-bit using a Microsoft program called Orca, and secondly, I created a transform to avoid the prerequisite checks that the installer launches (checking for ILM2007 and an empty management agent directory). While this allowed me to install the Outlook Live Management Agent, the installation for the configuration wizard failes, as it requires a component specific to ILM2007 FP1 which is no longer found in FIM2010. I did not find this to be a problem, as I simply configured the OLMA manually.

While the above approach worked, I’m hoping to take a look at using the second option I mentioned, as I expect it will be easier than editing the msi. Instead of installing the .msi, it can be instructed to just extract the OLMA source files. These files include the management agent XML files, so some time next week when I have a chance to build a second FIM server, I’m going to take a look at that option just for fun, because as I say, I expect it will be easier than the first option.

Once you have the Outlook Live Management Agent installed, it’s a simple matter of configuring the various screens within the MA in order to provision accounts into Live@EDU. Firstly, you need to have set up a special account manually within the Live Administration page called a service account. Once you have this service account, you can fill out the Management Agent as follows:

Configure Connection Information page:

If you are unsure as to how to create a service account, please refer to this article from the guys over at the Live service: http://help.outlook.com/en-us/140/dd490638.aspx.
Configure Additional Parameters page:
Configure Join and Projection Rules: (this section will vary for you if you run Exchange; we don’t run Exchange – at least, not yet)
  • Mailbox.Join: Alias->Direct->accountName (you can choose your own relationship here; this is what we chose to use)
  • Mailbox.Project: Person
Configure Attribute Flow page (Mailbox class on the left, metaverse Person on the right):
  • UserPrincipalName <- LiveID (LiveID is a custom attribute we added to the metaverse.person class, since our original source is not AD)
  • Name <- accountName (metaverse.accountName is our flat name that we also use as the AD sAMAccountName, for example lain.robertson; Name MUST be unique!)
  • DisplayName <- displayName
  • Alias <- accountName
  • WindowsLiveID <- LiveID
  • FirstName <- firstName
  • LastName <- lastName
  • DistinguishedName -> LiveDN (Live DN is a custom attribute we added to the metaverse.person class as a way of verifying a user has successfully been provisioned to Live)
Configure Extensions page (note: this section is only useful if you’re running the Password Change Notification Services):
For the pages that I’ve deliberately left out, they can be skipped (apart from the first page, where you have to provide a name for your MA).

From this point onwards, I’m going to assume you know what you’re doing with FIM, because it’s no different to ILM2007 in that you run Imports, Synchronisations, and in OLMAs case, the combined EDIDS step that performs the export, immediately followed by the delta import and synchronisation.

I hope this helps you get started!

Cheers,
Lain