The short answer is: Yes.
The longer answer is: It Depends
What are the basic ingredients you need? Collecting computer inventory data. Generating query reports. Deploying software products. Deploying software updates. Deploying configuration settings. Monitoring systems health status. The "it depends" part comes into play when your wishlist goes beyond this. It also depends on your computing and network environment.
Some would ask: Why build when you can buy? That's a valid question. Let's compare the trade-offs...
System Center products offer a ton of features and capability right from the box. Because they are renown Microsoft products they are also somewhat "commoditized" in many respects (replaceable labor is much more available than for a custom solution). There are also vast resources available from training and add-on products to support services. The same holds true for non-Microsoft products to varying extents.
A custom solution offers some advantages and some drawbacks as well. The good news is that because Microsoft has done an amazing and outstanding job of making their APIs easy to use, anyone can leverage them as they wish for free. Microsoft has already done that. System Center products make heavy use of readily available tools like WMI, the registry, XML parsing, .NET, BITS and things like Group Policy, scripting and so on. All of this comes at an offset "cost" in that it depends entirely on your abilities, time and experience level in various areas.
The most applicable parallel would be buying a car versus building a car. In this case, building it from retail parts, not pouring your own castings. I say this because Microsoft's efforts to provide built-in tools without additional cost is applicable to this rationale.
The key issues to consider are (a) are you inclined to develop scripts and components and "tinker" as well as (b) will you have sufficient time to create and maintain it all? If the answer to these questions is "I don't know" or your primary concern is "free", you might want to consider buying a solution instead of building one. The intangible costs could end up putting you in a serious bind. I don't want to talk anyone out of building their own custom solution. I've done it a few times. If you're inclined and seriously motivated and have the time, go for it.
If you haven't rolled up your sleeves and sat down to calculate all of the tangible and intangible costs - you need to. Do this for your existing environment and again for what you expect to gain from implementing your desired "solution". Don't forget to include your own labor costs. If your needs are small enough to justify building your own stuff, go for it.
Because each environment is unique, and every person has unique needs, I'll forego laying out a how-to discussion. Instead, I will just touch on the key building blocks you can leverage along the way to building your custom solution: graciously provided by Microsoft.
WMI
This is the plumbing system for Windows. It exposes properties, methods and events that allow you to probe, monitor, and even modify Windows settings for hardware and software. Most systems management software relies upon WMI/WBEM to access system status information and apply changes.
ADSI and LDAP
ADSI is the legacy interface to reading and writing to Active Directory, dating back to Windows NT days. LDAP is the newer, and far more robust, way to do that. Very useful for obtaining information about users, groups, computers, printers and metadata in Active Directory.
Windows Scripting Host
This is the ubiquitous scripting engine that allows you to run VBscript and Jscript (as well as Active Perl) scripts on any computer running Windows 2000, XP, Vista, Server 2003 and 2008. WSH exposes objects and classes which allow you to write scripts that interface with files, folders, the registry, event logs, services, and much more.
Start-Up Scripts
Start-up scripts are executed by computers as they are booted, before the logon prompt is displayed. Scripts which are executed during start-up are run under the local SYSTEM account context, so they have local administrative rights. This is a great way to deploy scripts in a network environment which require elevated rights. You can specify start-up scripts using a Group Policy Object setting.
Login Scripts
Login scripts run each time a user logs onto a computer. They execute in the same context as the user, so they may or may not have administrative rights (depending upon the user's rights), but they have access to user-specific information such as HKEY_CURRENT_USER registry keys, user profile folders and user environment variables. You can specify login scripts using a Group Policy Object setting or by modifying individual user accounts in Active Directory.
SchTasks
Added in Windows XP, this is the command-line interface (CLI) utility to the Windows Task Scheduler. You can create, query, modify and delete scheduled tasks on the local computer, or a remote computer. Read more.
EventTriggers
This is a command-line utility added since Windows XP that allows you to create a trigger associated to a specific event or type of event. For example, you can configure a trigger to execute a script when a specific error occurs. Read more.
Event Forewarding and Subscriptions
This feature was added in Windows Vista and Windows Server 2008. Event Forwarding is the configuration of sending local system events to a remote computer for centralized collection. Subscriptions are another feature which allow you to "subscribe" to events on remote computers, effectively pulling events from remote computers. Read more.
ADO
ADO (and the newer .Net flavor ADO.NET) are the underpinnings for programmatic interfacing with databases and data stores of various types. ADO is an ActiveX/COM API for connecting to, reading from, and writing to data stores such as Microsoft Access, SQL Server and Oracle among others. Within scripts, you can use ADO to connect to a remote database to query information, or to write information into.
CDOsys
CDOsys is the successor to the older CDO, which is another API for sending SMTP e-mail messages. CDOsys is often used within scripts to send email alerts.
The FileSystemObject
The FileSystemObject, or FSO, is an ActiveX scripting API for accessing, reading and writing to files, folders, logical drives and file streams. FSO is very often used for reading and writing files, creating and renaming files and folders, and checking dates on files and folders.
CACLS
An age-old CLI utility for viewing and modifying folder and file permissions at very granular levels. Great for crawling directory structures and changing permissions. Most often used within batch (.bat) script files to save time. Read more.
REG
REG.exe is a CLI utility for accessing the registry. REG allows you to check for the existence of keys and values, as well as reading, writing and deleting them.
NETSH
NETSH is a CLI utility for managing network connection and configuration settings. NETSH allows you to modify network connection properties, enable or disable network connections, modify Windows Firewall settings, and much more. This is indeed a very powerful command. Read more.
PowerCfg
This is another CLI for reading and managing Windows Power Management settings.
TaskKill
This is a CLI for terminating background processes. This can come in handy for stopping a process or service that may interfere with other tasks you need to perform. Such as stopping a service to allow you to modify or delete a file. The Sysinternals PSKILL utility is another way to do this (which I prefer over TaskKill).
Sysinternals Utilities
Once independent, Sysinternals is now part of Microsoft. Their renown PSTOOLS utilities are one of the most powerful and flexible collection of utilities for Windows ever released. Go to www.sysinternals.com to learn more.
XMLDOM
This is yet another ActiveX CLI programming interface for creating, reading and writing XML files using DOM (document object model) methods. If your scripts need to create, read or write XML file data, you should consider XMLDOM or use .NET methods (Visual Studio or PowerShell).
KixTart
KixTart is a public license scripting toolkit which has been used heavily by Windows Administrators for many years. It combines the power and flexibility of VBScript, WSH, REG, and BAT/CMD scripting as well as exposing useful environment values and powerful macro functions. Very easy to learn and extremely flexible. You don't need to deploy a scripting engine either, scripts are very portable and there are thousands of sample scripts available. Go to http://www.kixtart.org for more information.
PowerShell
This is Microsoft's next-generation scripting platform. More like a semi-programming language and engine than a traditional scripting platform, it exposes .NET classes and functions to runtime scripting. You can also compile components called cmdlets for reuse. It also encourages digital signing of scripts to increase security. PowerShell scripting requires the deployment of .NET runtime and the PowerShell scripting engine on each computer where it will be used. However, you can run local scripts against remote computers to query remote information and invoke methods remotely. PowerShell is a separate download for Windows XP, Windows Vista, Windows Server 2003 and 2008. It will be included with Windows 7 and Windows Server 2008 R2. Read more.
Conclusion
Ultimately, Microsoft has given us everything needed to build our own solutions for managing our computing environments. Users, Groups, Computers, and much more, can all be queried, modified and controlled in all sorts of ways. And the best part is that it doesn't cost extra. It's simply a matter of knowing what to do and having the time to do it. Of course, they also provide outstanding products you can buy and implement in much less time and achieve equal or (usually) better results. It's nice to have options.
No comments:
Post a Comment