ATTRIB is one of those commands back from the days of DOS which most folks don't even realize it's there. The purpose of the command, as its name implies, is to manage the attributes of files and folders. There are 4 attributes which it can manage:
We don't use it too much any more because the Windows GUI tends to allow us to manage the A, H, and R attributes just fine. One of the few cases where you would have to resort to ATTRIB is if the file is marked as a system folder. When cleaning up some malware from another person's desktop yesterday, I ran into this. In that particular case you can't make the file visible again, nor can you change it from being a system file without the use of ATTRIB. The following image shows that the hidden checkbox is grayed out when both of these attributes are set:
This is how the HOSTS file was set because the malware automatically inserted its own entries for common sites like www.google.com. For the average user, these settings means that even if they knew exactly where to navigate to, they wouldn't have been able to fix the file. Enter in ATTRIB. ATTRIB with just the name of the file or folder can tell us what attributes are set. Here's an example against a protected HOSTS file:
C:\WINDOWS\system32\drivers\etc>attrib hostsA SH C:\WINDOWS\system32\drivers\etc\hosts
Note that A, S, and H are set. Now one of the things about it being a hidden and system file is if I try to undo just the system attribute or just the hidden attribute, it won't work. Here's what you'd see:
C:\WINDOWS\system32\drivers\etc>attrib -h hostsNot resetting system file - C:\WINDOWS\system32\drivers\etc\hosts
C:\WINDOWS\system32\drivers\etc>attrib -s hostsNot resetting hidden file - C:\WINDOWS\system32\drivers\etc\hosts
As you can probably guess, the - (minus sign) tells ATTRIB to try and remove the attribute. If you wanted to add an attribute, like I did for this example, you would use + (plus sign) instead. However, back to how to solve this quandry, the trick is to toggle both attributes off at the same time:
C:\WINDOWS\system32\drivers\etc>attrib -h -s hosts
C:\WINDOWS\system32\drivers\etc>attrib hostsA C:\WINDOWS\system32\drivers\etc\hosts
And with the hosts file in this state, it was back to the way it should have been configured, with the exception of the entries inside of it I still had to clean up because of that malware. As a matter of fact, I had to use ATTRIB one more time on a folder in order to allow for a folder where the malware was hiding to be discovered by the security scanners.
This is one of those cases where an old round of DOS knowledge allowed me to do something you couldn't do through the Windows GUI. Knowing little tricks like these can often make a difference when you're troubleshoot or correcting issues like the one I was facing. Without knowing ATTRIB and how it worked, I don't know that we would have been able to clean the computer. The malware were rogue antivirus software packages and they were preventing other AV packages from installing and running properly. These rogue antivirus programs are on the rise because they prey on an innocent person's trust. The person will trust the information that just popped up is legitimate, and the rogue product gets installed. The end user doesn't know better and the software itself tends to be difficult to clean up.
This past weekend I was at the Columbia Code Camp, which was a rousing success with 6 tracks, a number of great speakers, and 165 attendees. This despite freezing rain and losing some speakers from North Carolina due to the weather. I was a volunteer and speaker (last minute on this one, to fill a slot for a speaker we lost due to the inclement weather), and I wanted to write a little about why volunteering for a Code Camp or SQL Saturday may be a rewarding experience. I've come up with four things I think one gains by volunteering. They are:
Free Training
The purpose of a code camp or SQL Saturday is to provide free training to IT professionals. They do tend to occur during the weekend. And if you're not a volunteer, it's easy to find a reason not to go. But when you're a volunteer, you know folks are counting on you, so you feel an additional responsibility to show. And once you get on-site, you get to attend the sessions during the time you're not volunteering. For instance, this past Carolina Code Camp I was able to hear great sessions from folks like Andy Kelly, and Jim Wooley. If I hadn't had to present, I would have been able to hear Alejandro Mesa's session, but alas it was at the same time as mine. I was proctoring the second of the two SQL tracks, or I would have made sure to hear John Welch, whose sessions were all in the first track. And all of this is provided FREE! You can't beat that.
Meeting People
Code Camps and SQL Saturdays are a great way to meet new people, people with like technical interests. Because of SQL Saturdays I've met folks like Jack Corbett, Rachel Hawley, Chris Rock (the .NET guy, not the comedian), Kevin Kline (the SQL guy, not the actor), Stuart Ainsworth, and Robert Cain. I've met folks like Alejandro at code camps. I've been able to build upon pre-existing relationships with guys like Andy Warren, Steve Jones, Brian Knight, John Welch, and Andy Kelly. They are real people, not just SQL and .NET gods, and you get to interact with them in the flesh. This is worth the time, in and of itself.
Learning How to Run Your Own
The Columbia Code Camp was run by Bobby Dimmick and C# MVP Chris Eargle. Chris has been to a lot of Code Camps and he had learned a lot about how one should run. Bobby is a naturally smart guy with a flare for organization and administration. Together they made a great team. One example of where previous experience came into play is the giving out of SWAG at the end. Chris found a neat application that automated the raffle drawings. It was originally in Ruby but he got permission and converted it to .NET. That thing probably saved an hour. Previous experience had shown him the need for one. By going to the other code camps, Chris was in a good position to help get one going in Columbia, which was nice. It's nice to do these local.
I need to say that if you've never run your own and you're not surrounded by folks who have run or been a part of conferences before, it can be a daunting task. When I first reported to the USAF, I was thrown into the middle of what was then called the Air Force Small Computer Conference as the special assistant to the conference chairman. A week long conference that averaged 3,500 attendees. There was a lot to do, from running down notepads (with a really nice organizer with it) that had to be put out to bid, to replacing a keynote speaker when HP's CEO pulled out, to handling the mess that was initial on-site registration once the conference began. But it prepared me well. The next year, I was co-chair of it and we renamed it the Air Force Information Technology Conference (AFITC). That year we had 5,000 attendees, video teleconferencing of keynotes, including a VTC session in to the conference attendees from then Secretary of the Air Force, Dr. Sheila Widnall, from her desk in Washington, D.C. I also participated in the next three on the technical side of things. Each time I volunteered, I was better equipped for the next one. And having done a big conference like AFITC, helping out with the Columbia Code Camp wasn't very stressful at all.
Learning Something More About Yourself
Every time I volunteer, I learn something more about myself. This particular time around I was less hands on and served more to assist Bobby Dimmick with questions and advice. Most of the time I was just a sounding board as he worked through issues that always come up in the planning for these types of things. That was a new role for me. I learned a lot more about listening to others and about the importance of letting folks work through some things on their own. I've always been in the midst of things, especially with the AFITC. Hands-on, immersed, with a ton to do and not a lot of time to do it. We always were scrambling. Planning for an AFITC began even before the current one concluded. We would start a week out setting up the site. And it seemed like there were always things to have to do the Sunday before with early check-in or Monday when the conference spun up. It was a great chance to watch a smart guy work through what needed to be done, come up with his own solutions, bounce them around a bit, and then see him execute. I know Bobby learned a ton and we're already talking about whether or not we can finally bring a SQL Saturday to Columbia, or perhaps even to Myrtle Beach, as Andy Kelly posed. We'll see.
So if you've not considered volunteering, please do. It's a great experience. You'll learn a lot, and not just in the sessions. You'll meet great people. And most of all, though I didn't list it as one of the big four, if things are done right (and even if they aren't), you should have a lot of fun. It takes a lot of energy, but at the end of the day, you get a huge sense of accomplishment as the event rockets through to completion. Find one near you, volunteer your time, and make yourself available, even if it's a stretch for you to do so. It is likely an experience you will enjoy and grow from.
We're making a final push to let everyone know about the Columbia Code Camp 2010, which happens tomorrow, January 30. It's being held in downtown Columbia, and there are 6 different tracks, including 2 SQL tracks (yes, 2 SQL tracks at a code camp). From the SQL Server side speakers include myself and SQL Server MVPs Alejandro Mesa and Andy Kelly. If you're anywhere near the area and want free training on .NET, mobile (including two BlackBerry sessions), and/or SQL Server, come on over and see us. More information can be found on the web site:
http://columbiacodecamp.com/
Paul Randal started a meme about three life changing events that brought him to where he is today. Brent Ozar tagged me, so here's my story of how I came to be a DBA.
Introduction to Computers
My introduction to computers started way back in 3rd grade. A group of us third graders got to over twice a week to the 4th-6th grade elementary school and participate in an accelerated class called Excels. And the school had recently acquired a brand new TRS-80 like the one to the right here. Naturally, we were among the first kids to get to play on it. And there I was introduced to BASIC and realized I had a knack for programming. Every time they rolled that computer into the classroom, I was the first one on it. Actually, I was usually the only one who wanted to jump on it, which suited me just fine.
From there I went to take a BASIC programming class where we were coding on VIC-20s. I moved on to C-64s, Apple IIs, and Ataris. This led to a computer competition in 7th grade where we were coding on Atari 800 XLs. By 9th grade I was writing door programs professionally for BBSes. We also ran a BBS that flipped from Wildcat! to Spitfire to TAG. And thus I entered into the computer profession as a professional at the ripe old age of 14.
The Air Force and Expectations
As a sophomore at The Citadel I had come to the determination that I wanted to serve in the US military. I was already in Air Force ROTC and there was a chance to pick up a full technical scholarship to try and secure a technical slot as an officer. So I took the appropriate steps, got the scholarship, and signed on with a contract. Air Force officer training typically happens between sophomore and junior year. I went to Sheppard AFB in Witchita Falls, Texas. For four weeks I went through officer training. But it wasn't easy. Far from it.
On day 2 I injured my shoulder. I later learned (while at training) that I had partially dislocated it and had damaged the soft tissue in the shoulder. It was so bad that I was ordered to begin physical therapy while at training. But my orthopedic surgeon cleared me to remain at camp to complete the course. The camp leadership, however, seriously wanted me to go home. If it hadn't been for the intervention of a sergeant who realized they were cutting some corners, I would have gone home and ended up repeating the next summer after having completed the bulk of the hard stuff.
In my mind, I couldn't go home. I was still able to function, and therefore, I should finish training. This is the mindset I learned as the son of US Marine. This is the mindset that was reinforced in me as a cadet at The Citadel. If you get hurt, even while at training, but you can go, you go. You don't get a do-over during a real operation. So that's what I did. For this mindset, I received comments like "Showed gross poor judgment for remaining at camp despite a serious injury." I was furious. When the Marines (father and uncle) in my family found out, they were furious, too. This experience jaded me towards the US Air Force. I honored my contract and did my four years, but over time I saw a big difference between the mentality I had of how the military is supposed to be and how the unit I was assigned to functioned. I was in a staff type unit and I had received orders to another staff type unit. How I gone over to an operational communications squadron, I probably would have remained with the US Air Force. But I didn't. I had four years of more of the same experience as I did at officer training and I wasn't looking for anymore. So I separated from Active Duty.
The good news is that during those four years in the US Air Force I continued to code (even though officers with a programming background and a programming specialty (AFSC, Marines and Army call it MOS) were no longer supposed to code... another reason I got so jaded). I learned ASP, got really familiar with IIS, NT, and, of course, SQL Server.
For Lack of an M. Div.
Another reason I separated out of the US Air Force is I wanted to serve as a youth pastor somewhere. I had done youth work under my church's youth pastor and when I broached the idea with him, he thought it was a great idea. I was hoping to go back to Columbia, SC, land a position, and go on to seminary at Columbia International University. I had some folks trying to help me do just that, but it didn't work out.
There were two strikes against me. Because I hadn't received my first call to a full time position, I hadn't being ordained (this is typically how it is done in Southern Baptist churches). I was looking for my first full-time position. No problem, a lot of churches said, if you have a Masters in Divinity, you're all good. But that meant I would have been completed seminary. Which is what I was hoping to get into and earn my M. Div. I couldn't get my foot in the door. Things would have been different had I been a graduate of a Bible college with a ministry related degree. But I was a graduate of The Citadel carrying a physics and a mathematics degree. So no one was willing to even interview me.
Facing the fact that I needed a job, in order to feed my family, I went back to IT. I was hired on as a system administrator working primarily with NT 4. However, when I got to the job, our help desk system reeked. We couldn't find tickets. The interface was terrible about that. We couldn't track tickets that originated out of Columbia. But the database back-end was SQL Server 6.5 and I had read/write permissions based on how the application worked. So in a short time we had an ASP based web site that let us track everything. And a lot of groups started getting really scared because we were suddenly calling about tickets that had sat in queues for months. They knew the system wasn't so great and that tickets would easily get lost. And they were using that fact. And then Columbia somehow started to track down its tickets. It's amazing how things turned around.
From there I went on to another job as a web developer, which turned into a senior DBA position, which led to the systems and security architect position. A year ago I had the opportunity to go back and focus on SQL Server again as a DBA. I jumped at the chance. And that's where I still am today.
Tagging:
Jack Corbett, you're up. You too, Mike Walsh. Marlon Ribunal, I think you'll fill out the list nicely.
As a father of two head-strong boys (inherited trait), I struggle with getting them to admit they are wrong when they know they are. Recently I caught my oldest dead-to-rights on something and he stood there and refused to back down. Of course, I was upset, but this was a teachable moment. So I spoke to him very evenly and calmly and said something to the effect of, "We all make mistakes and we're all wrong from time to time. You being wrong about something isn't going to change the fact that I love you and I'm proud of you. But when you are wrong and you know you are wrong and you don't admit it, you're being deceitful. I can't tolerate lying. You know that. And here's why I know you're wrong and why I know you know you're wrong..." and I proceeded to logically show him the pieces that blew apart his position. I want him to learn, while he is still under my roof, that admitting you're wrong is the right thing to do when you realize that you are. I didn't learn that until my first year of college.
At The Citadel, it is a family style arrangement for meals. Two freshmen are usually put on each half of a long table and their job is to serve the upperclassmen at said half of the table, and if they are lucky, try to get a bite to eat. One of those tasks is refilling the glasses when they get low. Certain upperclassmen do it certain ways. Some just want you to keep an eye on their glasses and when the liquid goes below halfway, you had better be filling up that glass. Others move their glasses to a certain point on the table and that's your cue. It was the latter that got me into trouble. At one particular dinner meal, Mr. Leroy Marshall and I got into it. Now Leroy back then was a sophomore and a giant of a man. I had a great deal of respect for Mr. Marshall. I was 5'7" and less than 130 lbs. Leroy probably could have snapped me in two. It's a wonder that he didn't. Here's why.
Right before dinner I had a phone conversation from someone in my family over grades. It was midterms and I would have a 3.5 or so GPA for my classes at that point. This particular person was furious that it wasn't a 4.0. So when I came to dinner, I had a huge chip on my shoulder. I was ready to fight. Even with someone like Leroy. And when his glass separated from his plate, I grabbed it and started to fill it up. He stopped me and asked where the glass was. I pointed to the spot where he had indicated we should pick up his glass from. He stated it wasn't there, but had just come dislodged from his plate. I then proceeded to argue with him. As a freshman you're never supposed to argue with an upperclassman. But I didn't care. I was so angry it didn't matter who he was or who was right. And the conversation got heated very, very quickly.
That's when one of the upperclassmen pulled me off the table and took me aside. He knew where the glass was and he knew I was wrong. He also knew that me fighting back like that wasn't normal behavior for me. And he knew that if I kept going, I was going to pay a heavy price for my refusal to back down. When he pulled me aside, his advice was, "Look, Leroy can kill you and we couldn't stop him." Very true. "But that's not the point." What? "You know you're wrong. And we know you know you're wrong. When you refuse to admit you're wrong, people lose respect for you."
That's not something I had considered. At that point I had stopped seeing red. I could have sworn the glass was where Leroy put it when he wanted a refill. But here was a second guy telling me I was wrong. Because of the respect I had for Leroy, the last thing I wanted was him to lose respect for me. I learned a valuable lesson that day: be willing to admit you are wrong. When you stick to your guns and refuse to do so, people begin to distrust you. They lose respect for you. As a professional, such as being a SQL Server DBA, once they lose that respect and trust, your ability to influence decisions for the better is gone. For my boys, whatever career field they choose to go, the same thing applies.
Not surprisingly, there are already vultures looking to take advantage of the tragic earthquake in Haiti for their own financial gain. The Internet Storm Center (ISC) has posted this:
Domains being registered about the Haiti earthquakes already
At this point we don't know what are being registered for reasonable purposes and which ones will be used by scammers and con-artists. Inevitable some are registered for use by the latter group. Therefore, be careful when interacting with anything purporting to be related to the Haiti situation. In the past these types of people have used email, websites, Twitter, Facebook, MySpace, and whatever other vectors they could to fool people into opening up something or going somewhere where they shouldn't. Times like these are when people let their guard down for more news, for a chance to help, etc. And these folks look to take advantage of that.
The best bet is to stick to known legitimate sources for information and for providing aid. Some of these are taking new forms, such as SMS donations on Twitter, so it can be hard to determine who is legitimate and who isn't. If you aren't sure, stick to the ones you knew before the incident were such. Also, look for legitimate sources of information to indicate who is real and who isn't. For instance, another ISC post:
SMS Donations Advertised via Twitter
They've listed a couple that should be legitimate. But if you're in doubt, go to the old stand-bys.
Yesterday we had a user receiving the infamous failed login attempt error (no, that's not a valid IP):
Login failed for user 'MyDomain\SomeUser'. [CLIENT: 192.168.1.201]Error: 18456, Severity: 14, State: 16.
Verifying the account in Active Directory, we saw no issues. Looking in the Security event log on the server where SQL Server was running, we saw that the operating system had authenticated the user properly. We knew the user was a member of a group that had access to the SQL Server. So at first, there was some head scratching as to what was going on. Now we make heavy use of domain security groups and it isn't unusual for a given user to have multiple security groups with access to a particular SQL Server. This user was no exception. When I saw the error and saw that everything else looked right, I suspected that one of the logins had a bad default database. My suspicions grew when we explicitly added the user's Windows account as a login to the SQL Server and the user was able to log in.
Now our policies say we're to use security groups, so we couldn't leave the user with access via this method (you don't really want to in a large environment because it makes clean-up difficult). I really suspected a bad default database configuration, so we removed the Windows user login and had the user retry. Sure enough, the error was back. At that point, I asked the user to specify the default database in the configuration. If you are using SQL Server Management Studio, you can do this by specifying the connection options, which you get to by clicking the Options button:
Then click on the Connection Properties tab and manually enter the database name:
If you click the drop down, the client will attempt to connect to the SQL Server with the default database and if there is an invalid default database, you'll get that login error. That's why the name has to be typed in by hand. Using master is a good choice, because every login should have access to the master database. Once the user manually specified the database, he was able to connect. My suspicions were confirmed.
So that raised the question, "Which login was the guilty one?" The user was a member of several security groups and with nesting, it was proving a little time consuming to determine exactly which one was causing him to break. A simple query reveals which logins are not set to use the master database as the default database:
SELECT [name], default_database_name FROM sys.server_principals WHERE default_database_name <> 'master';
And from there, it was a simple matter of checking a handful of logins. One such login, corresponding to a domain security group which the user happened to be a member of, was set to a default database which the login did not have access to. None of the user's other logins had access to that database, either. We had our login to fix. It was set where it had access to its default database, and the login problem was solved.
When I first reported to my duty assignment with the US Air Force, there were 3 sergeants in my shop. One was away on a special project and I wouldn't see much of him for the next six months. That left a staff sergeant I'll call James and a technical sergeant I'll carry Harry. Those weren't their real names, but they'll do for this post. If you're not familiar with USAF rank structure, a technical sergeant outranks a staff sergeant.
I come from a Marine dependent background. My father and one of his brothers, the uncle I was closest to, were both retired Marine enlisted. And I had heard numerous stories of dumb things new officers did thanks to these two men. As I approached graduation from The Citadel and pinning on my new second lieutenant rank, those stories only got worse. Finally, there was a break as my dad gave me some plain advice, "Find yourself a good staff NCO, tell him you know you need help, and if he believes you and he's a good NCO, he'll help you." For those not from a military background, NCO stands for non-commissioned officer and is generally used to mean anyone who isn't an officer. In the US Marine Corps, once one attains the rank of staff sergeant, he or she goes from being an NCO to a staff NCO. The US Air Force doesn't have that clear distinction, but I knew what he meant.
So naturally, when I got to my base and checked into my shop, I talked with both sergeants. I wanted to find a good NCO who could help me navigate my initial time with the US Air Force so I wasn't your stereotypical "butter bar." In talking with both James and Harry, it became apparent very quickly that Harry didn't want any part of helping anyone else. But James threw his arm around me and said, "Don't worry, Lieutenant, you stick with me and I'll take care of you." And James was true to his word. Even though we both changed shops during my four year tour, for the three and a half years James was still in, he looked in on me. If I didn't know the best way to approach something, I could ask James. Don't get me wrong, I had peers and more senior officers I could talk to, too. But for those I came into contact with a lot, James had more experience, especially when it came to the way the US Air Force and specifically my base worked. Plus, there's a different point-of-view from the enlisted perspective. And that view is valuable. So I found myself talking to James a lot over the years. And I was better for it.
Now for those keeping score at home, technically as an officer I outranked both James and Harry. But from an experience perspective, I started with virtually none. We often think of mentors as being someone who is higher up on the chain, but that's not always the case. I know that I learned a lot about the right way to do things and about leadership from James. The way he talked about taking care of those he supervised, the way he prioritized different tasks based on the real mission, and the way he looked to preserve a balance between mission and people (mission is always first, but you've got to try and take care of your people or you won't have anyone left for the next mission) was demonstrated in real life, in front of my eyes. When I had to make certain decisions about my own duties, about how to approach something, James always had solid advice for me to consider. He was also very willing to say, "I don't know," when he didn't know something. James was a great mentor for me. And I'll always respect him for it and be in his debt. When I am mentoring someone else, I try to take the same sort of approach James did with me. He had the right attitude and the right heart. I want to try and do the same.
But before I close the post, there's another guy in the story, and that's Harry. Harry wasn't interested in helping anyone else. He outranked James and had been in longer than James. I would be working more with Harry over time, and Harry knew it. So it was actually in Harry's best interest that I do the best job possible. But Harry only cared about Harry. I never saw him extend a hand to anyone else unless he was ordered to. Sad, I know, that he had risen to the rank he had (and he would be promoted further) with that kind of attitude. Harry was probably in the best position to mentor a young lieutenant, especially in that shop. But his attitude prevented him from doing so. I've seen folks like Harry over the years and every time I do, I shake my head. Yes, it takes time and effort to be a mentor. Yes, sometimes someone you're mentoring will let you down. But when you get that person who is eager to learn, willing to try, and wanting to get better, all that time and effort is worth it. James understood that. Harry didn't.
So if you're looking for a mentor, make sure you find not only someone who can help you grow, but someone with the right attitude. You want someone like James, who will throw his arm around you and say, "If you stick with me, you'll be okay," and means what he says. It's not just about who should be the most capable. It's also about whether or not the person is willing. And if you want to be a mentor, remember that your attitude is part of being a good mentor. It's not just about knowledge transfer. It's also about caring for your protégés and wanting to see them grow. You have to have the right attitude to be a mentor.
In September 1986 my family returned to Beaufort, SC, from a three year tour stationed at MCAS Iwakuni, Japan. My father was a Gunnery Sergeant in the US Marine Corps and we were returning to MCAS Beaufort. The first month or so we stayed with my uncle and aunt and during that time, I took to a manual typewriter that no one was using. I began to write stories and the like with it and I spent quite a bit of time hacking away on that typewriter. It was one of those two color typewriters, where the ribbon had both black and red ink, and this little lever which toggled what color would be used. When one of my uncle's rental houses opened up, we moved into it (our house, from when we were previously stationed in Beaufort, was still being rented), but I left the typewriter behind as it wasn't mine.
Fast forward to Christmas 1986. We head over to my uncle's house and there's a rather large present under the Christmas tree for me. When it's my turn, I tear open the wrapping paper and find that manual typewriter that I had happily used back in September. I was delighted with my gift. My father, however, was fuming. He was angry at his brother and sister-in-law for giving me a "used" present. They certainly had the money to buy something new and shiny. But one of the things I love about my aunt is she has always paid attention to what it was that I wanted. And she knew that the best present she could have given me was that particular typewriter. I'm the type of person who attaches memories to objects. And that one typewriter, for me, was better than any shiny new model she could have bought. I know that probably makes me strange, but she gave me exactly what I wanted.
What Do Our Customers Want?
This is an important question, and one I've struggled with. I have found myself falling into the same trap as what my father did that one Christmas. I hear what a development group or a set of end users want and I find myself thinking, "They say they want A, but what they really want is a shiny, fancy B." That's actually an arrogant thought on my part, because I am assuming I know better than my customer. How do I know what they really want? The truth of the matter is I don't.
Now there are two possibilities here. Either they know about that shiny B thing or they don't. If they say they want A and there's time, I should present B as an option. If they don't know about B, they may not realize it fits their needs better. And by taking the time to show B, I give them an opportunity to see that. In that case, everyone is happy, we choose B, and we move on. Now there are also possibilities like they see B, like B, but we don't have time to go with B, so we'll do A, and then plan a future change to implement B. Again, eventually everyone will be happy, and I've helped improve things for my customer.
But there's also this possibility that they've seen B, understand what B gives them, and have decided that B isn't what they need. So if I present B and they say, "Yes, we've looked at it, but it isn't what we want," I need to honor and respect that. Now I should ask a couple of questions to make sure that they're talking about the same thing I am, and if they are, then they've decided what they want and we go from there. Pushing what I want isn't respecting and honoring the customer. It could be seen as a slap in the face where I'm basically saying, "You're not competent to know what you want." Think about it for a second and you'll see how a customer could reach that conclusion. That's not where we want to be with our customers.
When We Push Too Hard..
So what if we're so busy pushing B that we fail to notice they really want A until after some feelings have been hurt? We own up to our mistake. No excuses. We apologize and admit we were wrong. This type of apology doesn't go along the lines of, "Well, you know, B has this feature and that feature and I thought you would really like it because of..." but rather, "I didn't do a proper job of listening to you. I will try and do better in the future." The first tries to insert an excuse. The second admits fault and recognizes that we need to do better. If you have any doubts as to which is better, imagine you were the customer.
I wish I could tell you that's what my dad ended up doing, but I honestly don't remember. See, for the rest of Christmas break, my and that typewriter were nearly inseparable. It won out over computer games and new G.I. Joe toys. I probably owe my typing skills today to that old manual typewriter. And at some point my father asked me, "You really like that typewriter, don't you?" My response was something along the lines of, "Yes, dad, I do. Can't really talk now. Typing up a story." And that's why I can't remember if my dad called up my aunt and apologized or not. I was too busy typing away on my typewriter.
Are There Exceptions?
Sure, there are always exceptions. For instance, what the customer wants may have a regulatory or legal problem. For instance, if what a customer wants violates a SOX compliance control that their organization has in place, what then? Then it's time to explain the issue. If that doesn't work, bring in the folks who are responsible for tracking and ensuring compliance is met. Let them explain why A won't work for them. At that point, you've put the right people together. In situations like these, that's all you can do. You get the folks who have some ownership of the issue together and you get them talking. That is to everyone's benefit.
And then there are the cases where the customer simply refuses to listen. They don't know about B, they don't want to hear about B, and they aren't going to hear about B. So what do you do? You give them A. But before you do, document that you tried to present B. You can't win by giving them anything other than A. The documentation is for later, in case they realize they need B, and they look to you to blame. It may not stop every bad situation, but it hopefully gives you an "out" to most unfavorable situations.
I have been re-awarded MVP status for SQL Server for 2010. It's a humbling honor, and I will strive again to live up to it throughout this next year.
I'm going to conclude this series on running a small user group with a topic that came up for discussion earlier in the week. A friend of mine, and a member of Midlands PASS, made a remark that whenever the officers of Midlands PASS talk about the group, we call it the group. We don't act like it's our personal possession. We don't take the attitude that if we weren't around, there would be no group. In our minds, the group belongs to the community at large. We have the privilege of serving. Sometimes it's hard. This is especially true when we have a lot of work and family obligations and making it out and supporting a meeting is another hit against our time. But despite the effort we put in, the group isn't ours exclusively. It belongs to everyone who makes up the group.
That line of thinking hopefully keeps us from prima donna attitudes. It also drives us to look at those in the group and make our best effort to provide speakers and a meeting setting that meets the group's needs. I know the moment we start thinking of the group as ours, as in the officers', we will start serving the group differently. We'll start looking at the group to serve our needs or goals, not vice versa. And that defeats the whole purpose of a user group in the first place.
I know, because I saw this first hand back when I was part of a Commodore users group back in the 80s. The group was formed and driven by one individual whose primary purpose was to acquire more commercial software. That got old, fast. We talked about trying to do more to expand the group, including having teaching sessions, etc., so folks with Commodores learned how to use their computers better (and thus found more value in them) and those who didn't own Commodores learned that they could get use out of a personal computer (this was back in the day when such a belief was not so widely held). He wasn't interested in such things. He paid some initial lip service to the idea, but it was clear within a couple of weeks that he wasn't going to give any time to that sort of thing in the meetings. And since he wasn't interested and since he believed as president of the group he drove what the group did, the group never got past his goals. As a result it died a rather rapid death after a promising start.
So it's important to remember that the group belongs to the group. If you have a leadership capacity in a group, keep that in mind as you strive to serve. The key word there is serve. You're there to serve the group as a whole. If you start looking at the group to serve your needs, that can quickly alienate the members of the group to the point where there is no group. Certainly it cause some folks who might have stepped up to help the group to shy away. And that puts all the load on you as the leader to sustain the group. That's not something any one individual can do for too long. We all need help, especially running something like a user group.
Because running a small user group is a labor of love, we look for time savings wherever we can to get done what has to be done. Most of this involves meeting announcements. You've got to advertise the next meeting, and it helps if you can provide little things, like directions, for those who may be coming to the meeting for the first time. Here are the tools we use:
The PASS Provided Website:
Having a hosted presence is nice. It gives a place to direct folks to see the latest meeting announcements, to get slides, and to sign up for future meeting announcements sent via email. PASS uses DNN and so that's what Midlands PASS runs on. This is available for any PASS chapter and we've obviously jumped in with both feet. One other really nice tool that comes with this hosted package is the ability to send out newsletters. When we have an announcement, I can put together a formatted message and shoot it through the interface in a matter of minutes. The solution will even do asynchronous emails and the like, meaning it reduces the chances of being caught by a SPAM filter. This is typically how we advertise our next meetings and other events of important in our area, like the upcoming Columbia Code Camp in January.
EventBrite:
EventBrite provides a great interface for providing information on events and tracking those who wish to attend. If your meetings are free, then there's no cost to use the service. That's really nice, because we can provide a landing page for a meeting announcement that includes clear information about what the meeting will be about, where it's at (complete with a mechanism to get directions to the place), and a way to track who is coming to the meeting. The latter is important when we are preparing to get food for the meeting. If you haven't looked at EventBrite, you really should.
Community Megaphone:
Community Megaphone is a great place to announce user group meetings. It's also a great place to find meetings in your area. I don't know if we have picked up an attendee due to Community Megaphone yet, but the interface is very easy to use and sooner or later it'll pay off. If you're in a larger area, it may very well be beneficial immediately. It's another free tool to advertise your user group, the work required to use the site is minimal, so given the price and functionality, it can't be beat.
SQL Server Central Blog or Wherever You Blog:
Obviously, since I blog here, I also tend to post meeting announcements here as well. This site probably provides the most visibility to any meetings we have, albeit the audience is not primarily local to the Columbia, SC area. However, I know a couple of folks who have seen a post on here and have come to the meeting as a result, so wherever your blogging, make sure you announce user group meetings when you can. You never know who might be reading your blog that's local. One of those folks may not even realize there's a user group nearby.
When we first started Midlands PASS, we tried to do it the way PASS suggested. We tried to get folks together to work on a set of bylaws, and the first try floundered. Myself and one other person attending the first organizational meeting. Needless to say, we tabled the effort until we could get more people to help. A year later, with no group around, folks remembered that I had originally tried to organize an effort but they hadn't seen a group. They asked if I would try again. So I did, but I didn't repeat the same mistake.
Instead of conducting an organizational meeting to work on bylaws, I worked on them myself. I called the organizational meeting, indicated it was more of a meet and greet than anything else, and we had a good number (for our area come out). We were able to validate the bylaws and elect officers right away. And we ran like for that the next couple of years with one slight hiccup in between. That hiccup was officer election. Basically, no one wanted to run who wasn't already an officer. So that left a couple of us holding two offices in order to make it through the year.
Midway through that second year, Andy Leonard came to speak. He also happens to be our regional mentor. He took the time to really hear out our pain points and he offered some suggestions. They were:
I'd like to say we jumped on his advice and did everything right the next meeting. We didn't. Some of these issues we're still struggle with. So let's look at each in turn.
Formal Structure:
We didn't start to go less formal really until about a third of the way into this year. That's nearly nine months after Andy gave his advice. The writing on the wall was in January when we tried to hold formal officer elections again. Basically, if you showed up, you got an office. Our bylaws also said a person could only serve in a role for two years before he or she would have to step down. Everyone looked at me and said, "You need to be president." At which point I said, "Oh, no you don't! The bylaws say I have to step down!" To which point they did the motion thing and next thing I knew, the bylaws were changed. And I was president again. So much for formalities.
So we're approaching when we should be doing elections again. But given then elections have not worked, and a lot of user groups around us are running fine without them, I think we're going to suspend things with regards to that. If one of the current officers wants to step down, we'll try and adjust, but it just doesn't make sense to try the formal approach when really people just want a place to get together, learn some SQL, trade some stories, and be a part of something.
Volunteers:
We've done a better job here, and that's because it started with the folks who showed up for elections this past January. We had needs, we laid them out on the table and we said, "We need your help. Would you consider serving in these areas?" Those new guys stepped up, three of them. They have been invaluable. There's no other way to say it. We were down to two returning officers, with a second one having to step down due to work responsibilities (traveling consultant based out of Charlotte). And throughout the year they've come through. Now it looks like we've got another one on board. But I've still got a long way to go to understanding how to get folks to involved. This is one of my weaknesses.
A Feeling of Belonging:
We've tried to work on this, making sure out meet and greet time starts early and lasts a good time. The officers make it a point to talk to everyone and to introduce new folks to the other members. If we find common points of interest, we try to get people talking to one another. We've done this a bit better, but we still need to work on it. Part of it is having a lot of operational folks, some of whom can't make two meetings in a row due to work. Others are about just having a better plan for getting folks together.
Advertise, Advertise, Advertise:
This we've done a ton better. We have a site thanks to PASS. We advertise there, on Twitter, through emails, through Community Megaphone, and on this blog. My work has a lot of IT folks (for Columbia) and I post flyers there. As a result we've been able to keep up numbers, even as we've seen turnover in the members. There are some regulars who have been with us all along. But we've lost quite a few folks due to the mortgage market imploding and two organizations employing DBAs going bankrupt. We've picked up folks from new organizations that we didn't know had database folks. So advertising has gone well. Of the list of four things Andy gave us, this has been our best effort.
Midlands PASS is a small user group. We average about 15 people coming to meetings, which is good for Columbia, but still puts us in the small user group category. Having a small user group can mean some challenges, and that's what I'll be blogging about over the next few days. Probably the biggest challenge we face each month is with getting speakers. We've had a great cast of speakers. Among the MVPs we've been able to line up in person:
We've had other great speakers who weren't MVPs, like Paul S Waters from our sister group, SQL Server Innovators Guild and folks from the SQL Sentry team. So it's not a bad list considering we're small and most folks have to travel to get to us. We're working on getting remote capability, something I'll address with our host for the coming year. So that list is comprised of those who have been able to find time to travel to our little place in the world. So what have we found that works? I'll give five rules that we try to follow.
Rule #1 - Don't Be Afraid to Ask
A lot of the folks I asked outright, "Hey, we're small, but you've got something to offer, can you come out this way?" And I have been continually amazed at the positive response from folks. My rule is the worst that anyone can say is, "No." If that's the case, then we move on and try someone else. Not everyone can get here or would want to get here, but we'll take quality speakers that do want to.
Rule #2 - Look for Piggy-Back Scenarios
We were able to get Brian and Andy because they had work in our area. Both were teaching classes locally so we worked our schedule to accomodate them. There have been some others who have come down our way, like Jessica M Moss and Jonathan Kehayias, but their schedules didn't permit it at the time. Jessica was neck deep with a client and Jonathan was going through the Army drill instructor course at Fort Jackson (Free time? You must be kidding). However, I've asked (begged) that if they are ever this way again, would they consider speaking at Midlands PASS. Again, the worse they can do is say no.
Rule #3 - Talk to Your Fellow User Group Leaders
Paul S Waters leads SSIG. Page Brooks and Chris Craft lead the Pee Dee Area .NET User Group. We were able to hook onto John Welch thanks to Peter Shire of the Charlotte SQL Server User Group. Peter also help us get hooked onto Kevin Kline's "Carolina Cruise," so we had the privilege of hosting him. And actually, I got in contact with Andy Kelly thanks to Peter as well. So maybe this should be, "Talk to Your Fellow User Group Leaders and Peter Shire." You can't go wrong with that.
Rule #4 - Let Your Members Do Some Legwork
One of our members had a connection with Wayne Snyder and ran down the details of getting him to come and speak. Sometimes your members will have connections you don't. If they can use those connections to get a great speaker, let them run with it. We had a dynamic presentation to Wayne, and our largest user group meeting ever. So this is a testament to what an individual member can do for the group. You don't have to sit in a leadership position to make a difference.
Rule #5 - Use Your Sponsors, but Be Careful
Peter Shire also works for SQL Sentry. And I will tell you that as a user group leader I always want to make sure that a vendor coming in doesn't give a sales pitch. The SQL Sentry guys are great. They come in and they lay down some real knowledge. They'll take five minutes at the end to show how one of their products addresses the pain points that they just got done talking about. But it's not a hard sell. And you leave a whole lot more knowledgable about SQL Server than their product. I don't know if that's a great marketing angle on their part, but I'm glad they take the time to come out to user groups and present on SQL Server, not on SQL Sentry. Likewise, Kevin Kline came and gave a great presentation on query performance. Yes, he works for Quest Software. Yes, Quest sponsored the meeting. And yes, Kevin used Toad and mentioned why he like what Toad did in a few cases. But they were relevant to the discussion at hand. And when you left the meeting, you learned a little bit about Toad but a whole lot more about SQL Server. These are great examples where vendors have helped us without doing the hard sale.
Now this isn't to say we haven't been burned the other way around. We have. We had some very heavy vendor pitches when we first started out. So now we make sure that a vendor understands that if they're coming in, we expect to hear about SQL Server, not their product. If they can't agree to those terms, then we don't want them. And this is a hard and fast line we've stuck to.
Yesterday I talked about taking notes using Google Docs. It's a great way if you've got multiple systems (especially with different configurations) to be able to store and organize information. But what about when you don't have a computer? And for this, I'm also including mobile devices, because they can often serve as a note taking tool. It's not unusual to see my eating lunch with my Blackberry out, typing in notes from what I'm reading. I can then transfer the information to another document later, and I don't have to lug around a laptop to do so. But there are times when none of that is feasible. So what do you do then?
You use a notebook. Or a notepad. Something small, portable, and built to write in. The idea is to get the information down. There is an additional step later to type in what was written down, but that's a better option than trying to remember and never doing so. Now you don't need a big, fancy notebook like Steve or Joe had, it just needs to be something you can use. And it should be something you can carry with you anywhere (within reason). The latter is extremely important. You want to have that note taking device with you wherever you go. You'll never know when a thought might come that you want to record, a task may get thrown on your plate, or you hear something you want to remember. Having that notebook or notepad is key.
This was a lesson I learned from a high school friend. He's now Dr. Brygg Ullmer at LSU and he's a smart guy. When we were in high school together he was doing things that left the rest of us in awe. Not just the fact that he was doing them, but the idea to do them in the first place. I remember one of his projects was to see if his computer could spit out an understandable report. He coded it in LISP, if I remember right, and he went around gathering electronic copies of reports and the like to feed into his program. For a relatively quick project, it did a amazingly passable job. I remember Brygg was always thinking and he was always on top of things. It was a couple of years later, when he came back to present to a group of rising 9th and 10th graders during the summer that I gained a little insight as to why: Brygg had a notepad with him at all times and he wrote in it a lot. He would go back over his notepad periodically and review what he had written down. It was a good system, one I'm still trying to emulate.
So if you don't have access to that computer or mobile device, go for the low tech solution. Make sure you get your notes down, whether you're reading a book, hearing a technical briefing, or listening to someone recite Keats. If you get a few snickers for pulling out a simple notepad, then it's only because the others haven't realized its usefulness. And that's to their disadvantage.
