In the last few years, some of the gains I've made toward making my role more focused on long-term efforts to continually improve and standardize our systems have been rolled back. The organizational details are boring and immaterial to the story; it boils down to the fact my team has less people to do more work, so much more of my time must be spent dealing with the churn of my team's daily duties. As a result, all parts of my job have suffered, and not just in obvious ways. My primary frustration with this situation is IT systems are entropic. They are constantly changing, and without clear and enforced policies, they get more chaotic as they grow. For a couple years, I felt like I was really making progress toward bringing my company's domains to an acceptable level of standardization, many of which we took over after their previous owners failed an audit or were essentially told to give us the reigns because we were better equipped for managing the services associated w...

In my post that covers my standard directory structure, I recommend using a third-level OU as the effective root of all non-domain controller members. "But," I can hear you saying, "what about all the computer objects that get created in the default Computers container?" To that, I say: block 'em. Do you have build procedures for new servers and workstations? Do you have agents or other utilities that need to be installed on all members? Do you have custom security or group policy settings that need to apply to certain computers? Do all devices need to undergo a security review before being joined to the domain? If so, this is the best first step to ensure all new computers are compliant before being put into production. Once you've established that there will be no creation in the default container, that logically means a few things: New objects must be intentionally created by either support personnel or approved automated systems. Elevated dir...

If you work in an operations center that receives or routes requests, your life is probably dominated by case numbers. You see them all day, and they likely represent the most granular version of a work task for you. They are invaluable to your job and allow you to quickly look up required information. Unfortunately, when you contact me (a systems administrator), only giving me a case number is almost worthless, especially when I may be away from my workstation. That made sound hyperbolic, but it's true. Whereas that number represents a completed task to you (transferred to a queue), it doesn't help me do any part of my job or tell me if I can even help the person who put in the case. It's just a random number. It never ceases to amuse and annoy me when someone from our operations center calls me (especially off hours), tells me they've routed a case to my queue, only gives me the number, then seems prepared to hang up, thinking they've done their job. Here ar...

In my company, my overall department often takes over environments for business units who have built their own, then found they lack the time/knowledge to manage it effectively. It then falls upon my team to reorganize the Active Directory domain to follow industry/internal security standards and best practices. This article covers one of the most common low-level offenses we encounter: shared service accounts. Like so many questionable decisions, using a shared service account seems like such a good idea on the surface. You only have to create one account in AD, you only have to record and track one set of credentials, app installers only have to remember one set of credentials, permissions for different processes will likely overlap (meaning you only have to grant the access once), etc. However, I have a personal story that will help highlight why you're playing with fire. Let's travel back to early 2008. It was the first week of my current job, and I was trying to learn ...