Sometimes it pays to take the line that “surely this must be possible already” – especially when it comes to Windows Server components that have evolved with each version of the operating system – in my case today with the humble Windows Event Log and Task Scheduler.
Automatically applied patches had triggered a FIM server reboot during the small hours of Wednesday last week, but the event had gone unnoticed … until questions were asked about user accounts that weren’t being provisioned. On investigation I found that a dreaded “stopped-server” error had occurred shortly after the reboot for one of the run profile operations, and since this had occurred during what I had defined as a “re-baseline” process, it had halted all subsequent run profiles from being executed. On re-mediating the problem, I figured something must be able to be done to automatically notify an admin of these types of events in the future.
There were 3 parts to my solution, all of which were ridiculously easy to implement:
Custom event log view
From the Windows Event Viewer console, I clicked on Custom Views with the right mouse button and selected Create Custom View … and defined a filter by specifying the FIMSynchronizationService as the event source and the status as either ERROR or CRITICAL – then saved it with the name “FIM Synchronisation Errors”.
Attach a task to the log view
This was where I actually had to start to think … and where I realised the email text was going to be rather limited, but would suit my purposes. There may well be ways to do token substitutions here, but I didn’t need to worry here so I didn’t. Note that you will need to specify a suitable SMTP server name on your network (I just grabbed the one from my FIM Resource Management Server config). I would also recommend specifying a distribution list as the target email address here rather than individual email addresses – makes for better manageability moving forward (no less than a FIM-managed d-list of course!).
I changed the task to “Run whether user is logged on or not” but left my own identity as the context for now – in a Production environment this should be a service account (or maybe even a managed service account were this idea to be supported).
… and turned on the “Run task as soon as possible …” checkbox. I also reduced the default run time limit from 3 days to 2 hours! I then clicked OK.
That was it – now all I had to do was test it, and suffice to say it worked first time (I just had to go hunting in my junk mail folder to find it!).
Create a basic email task on system start
I selected “When the computer starts” and clicked Next> … you don’t need to see the rest, and this worked first time too.
So … sometimes you don’t need the proverbial “sledge hammer to crack a walnut” … often it just takes a bit of hunting around to see what you get “out of the box” on the latest Windows Server platform.