Category Archives: worklog

Wins and SCOM

Spent much of today wrangling with System Center Operations Manager and my new backup WINS server. There’s a list of hotfixes that are pre-requisites for running OpsManager, including the agent, on Server 2008. One of the prereq’s requires .NET framework, so I’m ignoring that one (KB954049). My primary WINS server, also Server Core, has the OpsMgr Agent deployed just fine. I’ll figure it out, but my forehead is sore from bang on the brick wall.

Also noticed an occasional WINS EventID 4224, which represents a WINS db error which “This may or may not be a serious error.” I dug deeper, following the steps in KB168595 to take the two’s complement of the error value reported in the event to find the Jet Database error. The article links to a list or errors for the JetPack utility (not the Jet DB header file—I’m not downloading an SDK for this), the error cited in the example corresponds with the error code listed here. So my error code means “JetInit already called.” These codes also align with the current Extensible Storage Engine error doc at MSDN.

Since the service is functioning fine, I’ll call this a cosmetic error for now. But I wanted to record the detective work for posterity.

Also did some network troubleshooting and dope-slapped the WDS server. And spent much time banging head on Ops manager.

Glen Elder passed away. I didn’t know him personally, but as a member of the LGBTQA community, I felt his presence. He will be missed.

Tuesday – May 5

Spurred by some recent traffic on the Windows-HiEd list, I have looked into the Windows Update process on some of our Server 2008 Core systems. The thread was specifically with regard to KB article 953631, and that some folks have found that it installs repeatedly on Server Core instances and blocks other updates.

In examining the event logs on a couple of our Server Core system, I found that the update is indeed re-installing repeatedly, but it doesn’t appear to be blocking other updates.

First, I ran the systeminfo command to display the installed updates. KB953631 was not listed. I grabbed the WUA_SearchDownloadInstall.vbs script from Microsoft (I renamed it to Get-WindowsUpdates.vbs, in keeping with the sound PowerShell naming conventions). When I ran the script, it found and downloaded two updates, the KB953631 update in question, and KB955430. I confirmed that I wanted the updates installed, and the first update installed successfully, but the second failed (my initial searches didn’t explain the 0x800f082f error code). I reproduced the same behavior on another server core instance.

I tried rebooting the host, and running the Get-WindowsUpdates.vbs script again, and this time both updates installed successfully. (yes, the KB953631 update installed again). I reproduced this success on the other host as well.

So it appears that in our environment, the KB953631 update isn’t blocking other updates. I’ll confirm this after Patch Tuesday.

At the very end of the KB article is the following:

Note for WSUS administrators
If you approve this update for deployment in a WSUS environment, be aware that after you run the update, it will not be reported as "Installed." The update itself is not installed on client computers. The update scans for missing files and replaces them as appropriate. If a computer requires a missing file, the 953631 update will be reported as "Needed.”

Also, Server Core is not mentioned specifically in the list of affected operating systems. It might be worth asking what the expected correct behavior should be in this situation.

In my investigating, I also found an article in the Scripting Center the describes a PowerShell approach to manipulating Windows Updates. This might be nice when Server 2008 R2 is availabel and .NET and PowerShell are included, or other update-wrangling tasks.

Wednesday – April 29

Some Microsoft updates released yesterday, including Office 2007 SP2. TSGateway server Web and Terminal services didn’t restart gracefully. Investigating, I find some weird behavior from our Networker backup software. However, installing two outstanding updates and rebooting resolved the issue TS issue. Now I have two Networker issues to follow-up on: restoring .Net config files, and NDMP file restores missing ACLS.

Client with Dell Latitude d630. LiteTouch deployment created BDEDrive at S:, which conflicts with our standard drive mappings. Tried booting to Vista DVD, deleting the volume and then repairing, but that recreated the same system volume. Found a KB article that described renaming a registry key to change the drive letter that the system drive was using. Moved it to Z: and things started working normally.

Began deployment of new DC; drive cloning is s-l-o-w, and so is drive formatting.

Went on a wellness walk on Nation Walk @ Lunch Day; had a nice conversation with a friend from Health Promotion Research.

Checked-in on MSPSS issue; support engineer didn’t receive my email and data sent yesterday. Re-sent.

Some discussion of Vista software compatibility.

Added another laptop to test Wireless group policy.

Developed initial server admin group policy.

Wednesday – April 22

I’ve been working on revising and refactoring a Perl application that I wrote about four years ago to handle our domain account provisioning. Originally, it was a monolithic application, running on ActiveState Perl. Now it needs to run on a Windows Server 2008 x64 host. I use a couple of additional modules that are available from the excellent repository at UWinnipeg that include some compiled code. Rather than run the Perl64 version, and then having to compile my own DLLs, I decided to just install the 32-bit version of Perl, and continue using the modules.

The application is feature-complete, I believe, and is ready to be tried in production. When I attempted to run it under a service account, though, I encountered an error that I hadn’t received running it under my working account. I could repro the error with a simple one-liner:

C:\Perl\bin>perl -MNet::SSLeay
Can’t load ‘C:/Perl/site/lib/auto/Net/SSLeay/SSLeay.dll’ for module Net::SSLeay:
load_file:Access is denied at C:/Perl/lib/DynaLoader.pm line 202.
at – line 0
Compilation failed in require.
BEGIN failed–compilation aborted.

I checked my PATH, and verified rights to the file indicated. Things were in order and I was stumped. Some google searches turned up advice to check my PATH variable and confirm permissions. OK.

I used Process Monitor from SysInternals and filtered on the perl command line. Toward the end I found a couple lines indicating ACCESS DENIED to C:\Perl\bin\libeay32.dll.

procmon-perl-libeay32

Now this is not the file that was mentioned in the error, but I checked this one, and the SSLeay.dll that was there, too, and wouldn’t you know? They had different ACLs than the rest of the files. Perhaps the ppm installer didn’t assign the rights when it installed them? Whatever. I granted the service account appropriate access and that fixed the problem.

Huzzah!

Friday – April 17

Last night, I stumbled across this video:

Office Casual: How to work with the ribbon 

The Inside Office Online blog post for the video includes links to the interactive guides for the big five office applications.

I haven’t watched the whole thing, yet, but it also links to video of a presentation that discusses the evolution of the ribbon interface. My son and I watched the first ten minutes or so before bed last night, and he’s interested in watching the rest. Hurray for GeekKids!

Other agenda items, today:

I got the windump capture to work, using the local computer policy startup script setting. I did the same thing using the nmcap.exe command-line component of Microsoft’s Network Monitor 3.2. And one thing I learned is that I don’t know nearly enough about network communications.

Monday – April 13

Email catch-up, and checking some alerts on DCs.

Some assorted admin tasks:

  • Hung print job
  • User quota upgrade.
  • Check a couple department quotas
  • Advised department on security design for department files
  • Assisted debugging web app (IE client issues)

Work on autoprovisioning.

Review NetApp documentation on volume space reservations.

TGIF – April 03

Long week; lots of fun with home directories.

Covering backup while Cheryl and Frank are away.

Just found the PureText application. It provides a universal “Paste as unformatted text” hot-key. This is something I’ve been hankering for for a long time. Thank you, Steve Miller. This will now be a part of my standard toolkit.

Conferred with Greg about his trip to the Windows in Higher Education conference.

Looking at getting the HTC Touch Pro connected to the UVM WiFi network, having trouble authenticating.

Some search hits:

Doesn’t bode particularly well. Tried UVMGuest network; didn’t work either.

Enough for now!

Wednesday – March 25

Fixed permissions early (6 am) successfully with NetApp fsecurity command. That and the secedit tool made it quick work.

Did a little Russinovich-guided analysis of a minidump file created by EMC Networker.

Did some more work on UVM::AD module.

A number of other accumulated general administration tasks.

Wrote this perl one-liner to find the volume that contains a user’s homedir:

Z:\>perl -e"foreach (1..5) { $dir=qq{uvol_t1_$_\$}; print $dir, qq{\n} if ( -d '\\\\files\\' . $dir . '\\q-home\\g\\gduke'); }

might be worth turning that into a more robust command and turning it into an exe.

Horror! It appears that I forgot my laptop’s power supply at work. A wrinkle in the work-from-home-during-teacher-conference-early-release-days plan. [/sigh]

Tuesday – March 24

Home directory permissions issues.

Found: How to display the security permissions of a file from the filer which mentions the fsecurity command. Also found the white paper Bulk Security Quick Start Guide. Information about the Security Descriptor Definition Language SDDL at MSDN. From a comment on that page, I found Mark Minasi’s newsletter describing the SDDL syntax.

After poking at a few things with SubInACL.exe, I used the secedit utility from NetApp to create a security job file.

I created a new file, added a location”/vol/testvol”, then added the BUILTIN\Administrator user with Full Control. This generated a file containing the following:

cb56f6f4
1,0,"/vol/testvol",0,"D:(A;CIOI;0x1200a9;;;Everyone)(A;CIOI;0x1f01ff;;;builtin\administrators)"

The instruction are specific that you can’t remove the “Everyone” ACE, which is exactly what I wanted to do. So I edited the generated text file to remove that ACE, resulting in the following:

cb56f6f4
1,0,"/vol/testvol",0,"D:(A;CIOI;0x1f01ff;;;BUILTIN\Administrators)"

The command fsecurity apply /vol/path/to/file appears to have corrected the permissions just fine. I edited the file’s location to another affect volume and that worked as well.