Plain Text Prose

if you find it cumbersome to build up a total environment just to test products, you can find canned vms for limited use at the microsoft site " run it on a virtual hard disk ."  fyi - if you want to extend it from a 30-day trial to a 500-day trial, you'll need your technet subscriber id.

just a couple of links to some ways to address this. i find this crops up either occasionally on some of our servers, especially when concerning large packages like security updates. it happens during migration to new hardware occasionally, too. this is the typical error you'll receive: Package XYZ00234 requires a newer version (3) of source files and the new compressed files haven't arrived yet, current version is 2, skip E:\SMS\inboxes\distmgr.box\INCOMING\Z3AWAX9I.PKG multiple things you want to look at if you're running into this error: matt broadstock's method brian tucker's method andrew berges' method dx21 method this a really quick rundown on a way to get things moving. i don't suggest doing this unless you've exhausted the methods above outlined in the first 3 bullets. the dx21 method is the one i'm outlining here for reference. read it in full before you try this to understand what kind of unsupported posit

follow this kb article and note the special instructions for windows server 2003.  it specifies "to configure windows server 2003-based domain controllers, use the net logon service group policy "priority set in the domain controller locator dns srv records".  launch the local policy editor by using gpedit.msc drop down administrative templates navigate to system/net logon/dc locator dns records enable the setting "priority set in the dc locator dns srv records" adjust priority to proper value

this is cool enough to blog about (which translates to "do not want to forget this later").  in a previous post a long while back, i wrote up a short summary of how to setup an alert rule to receive all notifications for a specified computer group .  let's take that one step further, shall we? why do this?  imagine this scenario.  you're a domain administrator.  you decided to setup the alert rule specified above and tied it to your domain controllers computer group.  now you're receiving all the alerts for your domain controllers, just like you wanted.  and just like real life ... everything is going along happily until one day someone asks you to do something for them.  this time, they want a notification for security group changes.  not a problem!  you use a helpful little blog post like this to accomplish something pretty close to it.  (by the way, if you are doing this, just use parameter 3 for the group name.) oh to your chagrin, your inbox fills up wit

after a long holiday, the first thing i want to do is jump right into disciplining a bad agent.  i wish i could say it was something really painful to lament over.  unfortunately, it wasn't.  nor exciting.  it was like a cockroach: elusive and slippery.  i couldn't make it go away.  this is probably the third time that various corrective actions were done against this server. it seems the real issue was wmi corruption.  i have no idea what caused it or how it happened.  i suppose as far as wmi goes it's always a mystery.  anyway, it started off that way.  didn't quite end that way.  some of the errors i was seeing: The response processor failed to execute a response. The response returned the error message: The remote procedure call failed. Response Details: Rule ID: {E8665A8F-17B6-4C7C-BA62-CAC4E33C13CD} Response description: script : AD CPU Overload The response 'script: AD CPU Overload' has been running more than 300 seconds and exceeded t

before i start writing this, let me give some credit to robert mahle for getting me some information confirming stuff in this post. we've been working a bit (har har, no pun intended) trying to figure out how to decode the value of "asap" from the sms admin console into a spreadsheet. before i move too far ahead, some background for you... in this previous post about displaying advertisement info via a script, we ran into some confusion trying to decode the advertflags value. trying to get "asap" to show up just wasn't happening. the real confusion about this is "asap" is not treated like other schedule data that you'd find by looking for the sms_scheduletoken data type. usually it's held under assignedschedule. despite the fact that "asap" shows up in the sms admin console as a schedule, it's held under advertflags. the sdk confirms this: AdvertFlags Data type: uint32 Access type: Read/write Qualifiers: Bits When

we've been frustrated for awhile by the lack of flexibility in the admin console. particularly, i'm referring to the advertisement view. if you're trying to figure out additional details beyond "available after", "expires after", and "status" you won't be able to do it through the gui. i won't lie and say you can't get this information at all. you could... i mean, you could open every advertisement and look at the schedule. that would only take a few minutes right? while you're doing that, i'm going to get more coffee. alright, back. awake now. frustration has got to be the mother of scripting. :) seems like that's the only time we choose to go that route... and so frustration birthed a new script to help us along. basically a coworker wrote one up that would detail all advertisements and all additional information that you would normally want to know and presents the data in a spreadsheet. so what kind of