O R G A N I C / F E R T I L I Z E R: 10.06

Oct 27, 2006

sms: adjust permissions when using new tables...

okay, here's a little tidbit the next time you go messing around with creating new tables in sms. (uh, not that i have any knowledge of doing that.) if you've seen this error in web reports, then you'll know what i'm talking about. basically, in this scenario, you create a table, populate the data, match it up to something and everything works in query analyzer. the second you move it to a sms report... you get this:
An error occurred when the report was run. The details are as follows: SELECT permission denied on object 'myNewTable', database 'mySMSDB', schema 'dbo'.

Error Number: -2147217911
Source: Microsoft OLE DB Provider for SQL Server
Native Error: 229
essentially, the problem is the table lacks the correct permissions. it seems the best way to go about doing this is first to create a view off the table you've made. afterwards, apply these permissions to the view:
smsschm_users select
webreport_approle select

after that, your report should run just fine... i'll post more on what i was working on later... that is consequently not something i am doing in production or would ever, ever, ever recommend. :D

Oct 26, 2006

misc: they say that time changes things...

... but you actually have to change them yourself... -warhol you may have heard that daylight saving time is changing some of its parameters. in case you haven't heard, you should read more about it. in summary, we'll get four more weeks of daylight saving time: three weeks earlier (second sunday in march) and one week later (first sunday in november). go thank your congressman and the energy policy act. just so we're all on the same page, a computer keeps time in gmt format and uses the time zone offset to display the correct time. this means, you can't just sync time on a client and expect that the client will know about the new time zone parameters. the pertinence of a change of this magnitude is that your windows systems contain timezone data that is coded to increase/decrease the time by an hour based on currently known parameters. the other real problem is that microsoft (to date) has no plans to release a patch to address windows 2000 systems for the adjustments in dst. don't think it's a problem? wait until you see how outlook behaves... (think back to the australian 2006 commonwealth games). after november 6, 2006 ... for all of your systems above version 2000, apply the patch (once tested thoroughly, etc, etc, etc). for your windows 2000 systems, try one of these: using tzedit and create a .reg file of the dst changes outlined in this kb article and distribute. the folks at eeye have posted the contents of a .reg file which can also be used to accomplish the same thing. i'm not sure how long it'll stay around, so i've posted the contents of it below. REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\TimeZones\Alaskan Standard Time] "TZI"=hex:1c,02,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02,\ 00,00,00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\TimeZones\Central Standard Time] "TZI"=hex:68,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02,\ 00,00,00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\TimeZones\Eastern Standard Time] "TZI"=hex:2c,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02,\ 00,00,00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\TimeZones\Mountain Standard Time] "TZI"=hex:a4,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02,\ 00,00,00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\TimeZones\Pacific Standard Time] "TZI"=hex:e0,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02,\ 00,00,00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] "DaylightStart"=hex:00,00,03,00,02,00,02,00,00,00,00,00,00,00,00,00 "StandardStart"=hex:00,00,0b,00,01,00,02,00,00,00,00,00,00,00,00,00 if you copy paste the snippet above and don't have any leading spaces on the lines that start with "00," (underneath "TZI"), put two spaces before "00,". i'm not sure if it's actually necessary... but blogger loves to strip off leading spaces.

Oct 18, 2006

ds: useraccountcontrol passwd notreqd

sometimes when something gets far enough under your skin, you have to go looking for an answer. i've seen this flag come up quite a few times running oldcmp dumps. well, i finally got sick of just saying... "i don't know" and started looking for the answer. also, i couldn't really find any sources of information that specified conditions or anything like that. so ... it made a perfect topic. many thanks to the brilliant minds on the activedir.org mailing list and at microsoft.

alright, so when does this occur? you can't set a user account this way through aduc so you can rule out that someone accidentally did this mousing around. it seems that if you create an account through adsi and don't specify a password, you'll end up with a uac value of 546. (if you don't understand uac values, skim over this article.)

546 basically translates to:

  • normal user (512)
  • disabled account (2)
  • password not required (32)

it seems kind of odd not to require a password in this scenario. it was done, from what i gather, for ease of use. well, don't be terribly alarmed. the security risk isn't as great as you may think, though it does still exist. so at this point, the account cannot be enabled without a password. if the user tries to change their password, they'll be subject to domain policy. as long as there's a minimum character requirement, the password can't be a null value. sounds fine so far. the problem is, anyone with access to reset/change the user's password, can set the value to null. here's a useful adfind/admod command to remove the passwd_notreqd flag (courtesy of activedir grey matter):

adfind -default -bit -f "(&(objectCategory=person)(objectClass=user)(userAccountControl:AND:=32))" userAccountControl -adcsv | admod userAccountControl::{{userAccountControl::CLR::32}} -unsafe
make sure to view this page in ie. it won't show up right in firefox.

Oct 12, 2006

os: what not to do when using environment variables...

let's say you want to set a value to foo. so, you do something like this:

C:\>set foo = geniusboy

(you probably already see the mistake i just made.) so, now you want to retrieve the variable to use somewhere. you try to get it back by using this:

C:\>echo %foo% 

instead of getting back geniusboy, you get back %foo%. hmmm. where did it go? now you run this command just to list all the environment variables that start with f:

C:\>set f 
foo = geniusboy 

so alright, it looks like it took. why doesn't it come back with the first echo command? notice the spaces in the variable? try echoing %foo %.
C:\>echo %foo % 

even the value returned has a space. apparently, it is quite literal about those spaces. :) clear the value and try again (don't forget the space). now it works fine:
C:\>set foo = 
C:\>set foo=geniusboy 
C:\>echo %foo% 

mom: good resolutions are ...

...simply checks that men draw on a bank where they have no account.

so with that in mind, since there are obviously no good resolutions... don't you wish mom 2005 came with some manner of auto-resolving alerts? this has been something that has annoyed me for quite some time. i don't see the purpose of letting alerts linger in the wild for the expanse of eternity when most administrators don't bother using the mom console. they just want stuff in their mailbox.

here's a little script to do just that. i just took the scripts you can find all over the internet for resolving all alerts and added a date check so that only things over 5 days old are resolved. running this once a day by scheduled task helps keep things clean. the other benefit is that once the alert is resolved, the suppression goes away and notification fires again if the same problem is detected. just make sure to run it on the mom server.

if you want to change it to look for things even older than 5 days, modify this line:

If DateDifference(CDate(WMIDateStringToDate(objitem.TimeofFirstEvent))) > 5 Then 

change the value "5" to whatever amount days old you want. here's the script.


id = 255
Set objMOM = GetObject("winmgmts:!root\mom")
Set colItems = objMOM.ExecQuery("Select * from MSFT_alert where ResolutionState <> " & id & "",,48)

For Each objItem in colItems
    If DateDifference(CDate(WMIDateStringToDate(objitem.TimeofFirstEvent))) > 5 Then
        WScript.Echo objitem.name
     End If

Function WMIDateStringToDate(dtmDate)
    WMIDateStringToDate = CDate(Mid(dtmDate, 5, 2) & "/" & _
    Mid(dtmDate, 7, 2) & "/" & Left(dtmDate, 4) _
    & " " & Mid(dtmDate, 9, 2) & ":" & Mid(dtmDate, 11, 2) & ":" & Mid(dtmDate,13, 2))
End Function

Function DateDifference(myDate)
    DateDifference = DateDiff("d",myDate,Now)
End Function

Sub ResolveAlertObject(objItem)
    If (Not(objItem Is Nothing)) Then
        If (objItem.ResolutionState <> id) Then
            objItem.ResolutionState = id
            Call objItem.Put_
        End If
    End If
End Sub

Oct 4, 2006

os: dhcp ras leases?

if you've found your dhcp scopes full of addresses that specify:
  • type: DHCP
  • unique id: RAS
and want to get rid of them, try this command: netsh ras ip set addrassign pool