Skip to main content

Posts

Showing posts from October, 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

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 adjustme

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 passwor

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% %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 FP_NO_HOST_CHECK=NO 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 % geniusboy 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% geniusboy

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