I was going to write a post on how to install and configure your own virtual SSL-VPN server as I had in mind to make one myself as a means to surf safely while on hotspots and to access my System Center lab at home.
I’m not gonna do that. Instead I just want to point to this free, already pre-configured, OpenVPN Virtual Appliance. Just follow its instructions and it will work quite nicely.
Have fun.
Here a link to the System Center Operations Manager 2007 R2 Documentation for those of you out there who keeps asking of its whereabouts and then tell me to not tell you to google for it.
So now I can direct you to my site, tell you to click on “OpsMgr 2007″ to the left and browse through my posts instead of wasting precious time on googling and pretend being more helpful.
To the rest of the world, sorry for wasting your time!
Happy now, eh?
Here’s a little something-something for the wicked.
Me and my apprentice is currently decommissioning an entire Management Group with a thousand (-ish) agents. Long story short, we got a new Management Group, migrated all the agents, added a couple of hundreds more, deployed a bunch of gateways and now we are shutting down the old one.
Now, uninstalling the old Management Group from all the agents is a breeze using SCCM and handling the few 20-ish servers that are left is not a biggie either. Shutting down ACS, however, is a different matter.
Although you do configure your forwarders using Operations Manager, removing the management group you were running ACS in does not mean the agents will shut down and disable the AdtAgent service or stop trying to forward audit events to your collector. Now, selecting 10 agents at the time and running the “Disable Audit Collection” task–in case you did not know, there’s a limitation on how many agents you can run a task on in the Operations Console–is not my idea of a jolly good day and since Powershell is a bucket of joy in comparison; here’s a script for you all!
It is zipped to avoid security alerts, but as with any script found on the internet I implore to to read the code before actually running it.
Anyway, you can use it in a couple of ways.
To run it interactively, just go to the directory where you unpacked it and run it. You will be requested to enter the FQDN of you Root Management Server and a wildcard search for ACS Forwarders.
For example:
PS C:\..\Scripts> .\DisableACSForwarders.ps1 Root Management Server: rms.teknoglot.local ACS Forwarder name (wildcard): *.teknoglot.local
You can also run it with parameters (for scheduling?) like this:
PS C:\..\Scripts> .\DisableACSForwarders.ps1 rms.teknoglot.local *.teknoglot.local
If you need to run the task with different credentials there’s a switch for that. Just add -UseCredentials to the command and you will be prompted for it.
Like this:
PS C:\..\Scripts> .\DisableACSForwarders.ps1 -UseCredentials
As you might already have realized, the wildcard search does not require actual wildcards. If you only want to disable the ACS forwarder on a single machine, just enter it’s FQDN. As for what wildcards it will accept; anything supported by the powershell -like operator is valid.
[UPDATE!] You might get false failures when running the script on clustered machines because of a bug in the AC Management Pack
For the source code, read on!
I’ve had this little visio drawing lying around on my desktop for a while now and I thought that it might be a nice thing to share.
It is nothing ground breaking at all and all the information is available at the Operations Manager 2007 R2 Supported Configurations page on Technet, but I find the visual map easier to read and I use it personally to quickly look up all port openings for the most common components in Operations Manager.
It is missing a few components like ACS, AEM and XPlat, but I usually just look them up when needed.
Have fun!
For quite some time now I’ve had this idea spinning around in my head to write a couple of blog-posts about some of the more useful techniques available when building management packs. Many of these techniques are already described on MSDN and Technet- or other blogs as well as on various forums, but often no more than small bits and pieces of them and I have yet to see some humanly readable information about how to tie them together into a useful management pack. I say “humanly readable” because the information you do find online so far may be clear and somewhat easy to understand for someone with a system development background and a pretty good idea of how object oriented development models tend to work. But the real life System Center Operations Manager engineer–you know the one who get those “do you think we could monitor our …-system too?” questions a couple of times a week, you know… you (most likely, being here)–tend to have a completely different background. Yet as their OpsMgr environment grows, so does the demand for custom monitoring and all of a sudden the former server engineer are now also a developer. A developer who has never before had the need to grasp such abstract concepts as classes, instances, inheritance and who probably never before have had any reason whatsoever to write any XML code.
My idea for this series of posts is to shed some light into the world of the authoring console and modules and cookdown and so forth. I am by no means an accredited author, but I will do my best to stay human in this venture and in plain english try to explain why and how you do certain things when going from Management Pack templates, rules, monitors and the safe haven that is authoring in the Operations Console into making your scripts resuable, easy to extend and prime for cookdown using the Authoring Console and XML.
To give the series some kind of context and at the same time not only be a matter of examples I will base them on a fully functional management pack that discovers and monitors all Windows services that are set to automatic startup. I know there is other similar management packs out there but I haven’t fancied any one of them yet, and since I had the idea of writing this series I decided that building a new one would be a good way to go. Some of the interesting features with this management pack is:
Most of these features will be described thoroughly in later posts in the series and as development of it progresses I will document what I do, how I do it and why I do it in certain ways. Hopefully you will learn something new through this and get closer to becoming that MP Dev the organization asks for.
In the mean time, feel free to download, look at the source code (which it by no means perfect) and try it out.
The TG WinAutoSvc monitoring management pack is available for download here:
http://code.google.com/p/tg-winautosvc/downloads/detail?name=TG.WinAutoSvc.xml
The latest revision of the source code is located here:
http://code.google.com/p/tg-winautosvc/source/browse/trunk/TG.WinAutoSvc.xml
A small word of advice though. If you implement this in your environment, remember that you probably have alot more automatic services than you would expect. Because of this, discovery is disabled by default.
Best of luck, and enjoy!
I think I got the server running ok now.
I’ve been fiddling about quite alot and unfortunately don’t know which one action that fixed the problem. If I do figure it out, I will post it here.
Site performance should be a bit better now.
I, as well as others, have noticed some slow performance from my blog lately and I just wanted to let you know that the root cause have been identified as a bug in on of the crypto libs on the server.
I haven’t found a working solution yet but are trying to keep an eye on the site regularly to be able to bounce the problematic services when they start to act up.
Hopefully there will be a fix available soon.
Sorry for any inconvenience in the meantime.