Question 1 - "I have about 50 to 60 desktops and laptops, and about 10 servers in my AD environment at work. I don't have a patch management product yet, I currently patch my Windows machines manually or using scripts. Is there a good reason *not* to use WSUS?"
Answer: First off, you need to start drinking. Your doctor would agree with me. I think. Well, anyhow, if your environment is built on versions of Windows which can be supported by WSUS, then the answer is NO: there isn't a "good" reason to *not* use a free product that at least gets you closer to the goal line. How's that for a double-double-double negative statement? I should've been a politician.
Are there better products? Sure. For free? Maybe. Is WSUS "good enough" for most shops like yours? Probably.
Question 2 - "My significant-other spends a lot of time reading, studying, and playing in a lab to stay current with his/her career. Is there anything I can do for him/her?"
Answer: Yes! Feed them. Scratch their back. Rub their feet. Make them laugh. And most important, feed them some more. They need to be sure to return the favor though. My wife is amazing, but I have to remember to rub her feet too (she deserves it).
Question 3 - "I have scheduled tasks running on computers which run under the local SYSTEM account, but when they try to execute commands or access resources from remote UNC shares, they are denied access. What am I doing wrong?"
Answer: Two things... the first problem is that you're not sending me cash to help me pay my bills. Just kidding. Second, you didn't grant sufficient permissions to the share and/or the underlying NTFS folder path. Remember, the local SYSTEM account runs as a proxy for the computer itself (when operating in a domain context). So, when it knocks on the door of a remote shared resource, that resource sees the domain computer account in the peep hole. (you thought I was going to say glory hole, didn't you? sick puppy you are).
For example, if one computer is "DT1234" and is running a task that requests a connection to server "FS0005", then that server will see "DT1234$" (they append the dollar sign to indicate you paid a lot of money for that license. ha ha . kidding again). Actually, if the domain is "constoso.com", then the server sees user "CONTOSO\DT1234$" (NetBIOS name + computer sAMAccountName) knocking at the door.
By default, domain-joined computer accounts are not members of the AD domain "everyone" or "domain users" security groups. They're not even members of any group (by default) besides "Domain Computers". Therefore, you need to grant rights on resources to that domain security group, and your domain-joined computers should be able to knock at the door and get some free food.
TIP: a simple way to test local SYSTEM access to remote shares, is to use the "psexec.exe" utility (Microsoft/Sysinternals) with the "/s" option to launch CMD.exe. Then within the command console, running in the local SYSTEM context, try to connect or query remote resources to see what happens.
Question 4 - "I'm building a custom app/script that helps manage things within System Center Configuration Manager 2012 R2. It needs to read and write information as well, but it looks like I can do that by ADO and SQL commands, or by WMI and WBEM commands. Which should I use?"
Answer: (long, long inhale.... get ready, here it comes...) Okay. Both. No, wait. Neither. No, wait, that's wrong. Both. Sort of. Hold on. This may seem a little complicated. And even if it wasn't complicated, I'm a professional, and complicating things is what I get paid to do. That's not true either. Just a minute. Okay. So drink up, strap in, or strap on, or buckle up, whatever...
You know how they say "never say never"? Well, NEVER, yes, that's right, I just said "NEVER", ever write to a System Center Configuration Manager database directly. All "write" (aka update/insert/delete) operations should be done through WMI/WBEM statements. I'll get to the "why" in a minute.
First things first: While you absolutely can request information from the database using WMI/WBEM queries, I recommend that you do your read operations directly from the SQL Server database, rather than via WMI/WBEM. The reason is that they're going to perform faster than WMI/WBEM requests (assuming you know how to form proper T-SQL statements). More importantly: WMI/WBEM query statements are way more limited than T-SQL as far as what kinds of operations you can perform. For example COALESCE, TRY_CONVERT and CASE statements, to name a few. And I won't even get into things like DATEDIFF, CAST or SUBSTRING.
Next, the reason you shouldn't push anything into the database directly is that SCCM relies on a delicate, complicated and, let's be honest, confusing-as-hell sequential process for handling change requests. That is, updates, additions, deletions, and so on. Each request is queued, prioritized, processed and logged. The "processed" part involves even more sequential handling with triggers and more logging, and if you go around back, break open the window and climb in the back room, the alarm will go off and the SWAT team will repel down from helicopters and kill you. Okay, not really. But it will very likely break your SCCM site entirely.
When you submit requests properly using WMI/WBEM requests, they are like well-trained school kids lining up to go to the cafeteria. They get their lunches, sit down, eat and smile the whole time. When you shove them in directly via ADO/ADO.NET, shit will just break. Trust me. If you don't trust me, go ahead and setup a lab environment and kick those tires. When the air blows out, don't come crying to me.
Finally, or thirdly? - if you plan on making the same types of requests for information (read operations, that is) and they involve SQL "JOIN" statements, I recommend you create some VIEWs and apply indexing. SQL will outperform application processing like Stephen Colbert having a debate with your dead cat. If you've been strapping together messy "SELECT blah FROM whatever LEFT OUTER JOIN something ON this = that..." and so on, in your script code, STOP! Do that within the database (or create another database on the same server to pull data for abstraction and aggregation work, etc.). So, to summarize all that blabber...
READ == Direct from the Database (SQL + ADO or ADO.NET)
WRITE == Through the WMI/WBEM interface
If you're thinking which is "faster": COM scripting or .NET scripting (e.g. VBScript vs. PowerShell), it depends on what you're doing, but for most things it's break-even. The biggest factor will be where the bulk of logic handling and processing is being done: in the database/WMI request itself, or on the information obtained therefrom. I can already sense the .NET nerds flipping out right now. Spitting coffee through their nostrils. Exclaiming "WTF?!!", knocking over their stacks of stale donuts and breaking pencils. Oh well.
Question 5 - "My company is looking for a good service request ticketing system product. What products would you recommend?"
Answer: None of them. Or all of them. The problem is that every organization that's existed for more than a few years, has evolved their own internal processes for handling requests. Staffing varies. Methods vary. Resources vary. The retail products you will try on will almost certainly be like a "one-size fits-all" suit. Lot's of Velcro straps and adjuster things to help you pull in the tight spots to fit better. But it's going to feel like that too.
Most off-the-shelf products will expect you to make some concessions with regards to "how" you do things. That's not always bad, though. Read up on ITIL, and even if you hate ITIL, it's good to have something to base your processes upon. That or a suitcase full of drugs and a fast getaway car. I have no idea what that's about though.
If your environment has implemented ITIL with gold medal effort, you may do really well with almost any off-the-shelf product. However, I haven't seen an ITIL gold-medal shop in my lifetime. I've heard stories of them, but I've never seen one. Kind of like unicorns and leprechauns.
I see two options: Build your own with whatever tools you have, or buy one and suck it up. Just be warned: The bigger your organization (staff and customer numbers), the more work it's going to be, for either direction you choose. Be cautious of vendors offering "customization" services too. That's their bread-and-butter. Am I a bit pessimistic? Yes. It's a lot like shopping for document management solutions, or vacation homes. I wish I could afford a vacation home. Heck, I wish I could afford to take a vacation.
Th-th-that's all for now, folks. Have a good week!
No comments:
Post a Comment