Tag: PoSH

Cloudflare as Dynamic DNS [#cloudflare #mikrotik #script]

Background I have, for a time, been using CloudFlare for CDN, Optimizations and DNS Management for this and a few other domains. At the same time, I’ve been using DynDNS to provide name resolution to my home network/lab. Browsing around the CloudFlare JSON API I noticed that I can update DNS records through some fairly simple HTTP GET requests, and since the RouterOS (the operating system used by Mikrotik’s routerboards) has support for some pretty decent scripting I decided to let my router update CloudFlare for some custom and free dynamic DNS resolution. Attribution My current script is a modified version of a script developed by Konstantin Antselovich. Original script: http://konstant1n.livejournal.com/9759.html Original Author website: http://konstantin.antselovich.com/ Thanks! How you do it What you need RouterOS v6+ for HTTPS support Cloudflare API key, aka “Token”, found at the account page Cloudflare DNS Zone name Cloudflare Record Id (more on that later) Cloudflare subdomain name Name of the external router interface

OpsMgr 2012 Agent Failover – A Faster Script with Wildcards [#opsmgr, #powershell]

Now we’re gonna make things even faster! In the previous post on the subject of Agent Fail-over in Operations Manager 2012 we created a script that will go through a selection of agents and make sure that they all have up-to-date fail-over settings. We are doing the same thing in this one, but making it go faster. In my lab, it’s about five times faster in fact and I only have about 20 agents to play with. Not really a big deal, but scale it up a bit and add a few thousand agents and the pay-off will be very significant. As usual, the script will work as is, but it really is more to show the concept. You would have to add filtering to make sure you don’t mix agents behind gateway servers and agents behind management servers. Giving an agent behind a gateway a management servers as it’s fail-over server will likely not help you in any way. We will pretty quickly go “advanced” this time, so buckle up. 😉

OpsMgr 2012 Agent Failover - Simple Script with Wildcards [#opsmgr, #powershell]

In the last post, OpsMgr 2012 Agent & Gateway Failover – The Basics, we looked at the basics of the Agent and Gateway fail-over configuration cmdlets and how to use them in a direct and interactive setting. This is absolutely useful when you got this specific agent that you need to configure with a specific fail-over management server. To spice it up a little, we are going to add a little intelligence to it and enable wild-card selections while at it. The scenario we are building this script for is that now and then you want to make sure that certain agents have fail-over management servers configured. You also want to make sure that all management servers that are not the primary management server of any selected agent will be in that list of fail-over servers. This would include any new management servers as well as exclude any removed ones. In short, make sure your agent fail-over settings are up-to-date with the current environment.

OpsMgr 2012 Agent & Gateway Failover - The Basics [#opsmgr, #powershell]

I have previously posted a few scripts on managing and configuring fail-over management servers on gateways and agents in System Center Operations Manager 2007 R2. Now that System Center 2012 Operations Manager is RTM and users are starting to explore the differences between the versions I see more and more questions on how you do, in OpsMgr 2012, what you did in OpsMgr 2007. In a few posts henceforth I will go through Agent and Gateway server fail-over configuration and management. In this first post I’ll look at the very basics of fail-over configuration, the cmdlets to use and some one-liners.

Quick-Hack: Send SMS through Powershell [#powershell]

Decided to do a quick-hack/fast-publish on this one as I have had a bit less time to create a nice clean production-ready version as of yet… and people has been asking about how far off the article is. What this script does is to send a text message using a GSM/GPRS modem connected to a local (or LAN-connected with local drivers) serial port using Powershell. Disclaimer! This script “works” but is not fit for production. See it as an example of the general concept to evolve and adapt into something worthy of production use. What’s missing in the latest iteration is: A working Event-Handler to deal with asynchronous call-backs. Support for AT+MSGW (write to modem memory) Reusing messages in modem memory for multiple recipients. Various error- and exeption-handlers. Actually verifying that the modem is AT-capable. Querying the system for available modems and their ports. The Script So, a short note before digging into the script. Prerequisites for this script is that you have identified which COM-port to use and it’s supported baud-rates and whether it supports DTR or not. If you do not know what the hell I am talking about, you could probably have it work with my preconfigured settings anyway. If you are unsure about if your modem supports AT commands you could open a serial connection to the modem using Hyperterminal or PuTTY and run AT+CMGF=1. If supported, the return should be OK. If it is not supported (you get ERROR instead) you would have to use PDU-mode which require a bit of hex-encoding of your messages. This is nothing I have had to do yet and will not be including in this script. Maybe in the future. Maybe. So, looking a some powershelling then. First thing would be to connect to the modem. # Create your instance of the SerialPort Class$serialPort = new-Object System.IO.Ports.SerialPort# Set various COM-port settings$serialPort.PortName = "COM1"$serialPort.BaudRate = 19200$serialPort.WriteTimeout = 500$serialPort.ReadTimeout = 3000$serialPort.DtrEnable = "true"# Open the connection$serialPort.Open()

Bulk disable ACS Forwarders (with wildcards)

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.

Change Gateway Powershell Script

This script has pretty much already been covered in my previous post about Changing or Replacing an Operations Manager Gateway Server. This time I’ve basically put parameter support in it to make it easier to use. Here’s the script anyway. Param($OldGW,$NewGW)$OldMS= Get-ManagementServer | where {$_.Name -eq $OldGW}$NewMS = Get-ManagementServer | where {$_.Name -eq $NewGW}$agents = Get-Agent | where {$_.PrimaryManagementServerName -eq $OldGW}$agents = $agents"Moving " + $agents.count + " agents from " + $OldMS.Name + " to " + $NewMS.NameStart-Sleep -m 200Set-ManagementServer -AgentManagedComputer: $agents -PrimaryManagementServer: $NewMS -FailoverServer: $OldMS To use it, create a textfile called ChangeGW.ps1 and paste the code into it. Save the file somewhere neat (maybe C:Scripts) for easy access. If you don’t feel like copy/pasting, you can download the script here. To use it, open the Operations Manager Command Shell and type: C:\ScriptsChangeGW.ps1 <old.gatewayserver.dns.name> <new.gatewayserver.dns.name> For example: C:\ScriptsChangeGW.ps1 gwserver01.domainname.local gwserver02.domainname.local

Replace/Change a Gateway Server

Description of problem If you are looking into replacing an (or just switching to another primary) Operations Manager 2007 Gateway Server for any reason, there’s a little more to consider than just right-clicking the clients and selecting “Change Primary Management Server” in the Operations Console. You could end up with agents not being able to connect to the Management Group at all due to a small problem with the order in which Operations Manager do things. Here’s basically what happens: You tell Operations Manager to change Primary Management Server for AGENTX from GW1 to GW2. The SDK Service (i guess) tells GW1 that “You’re no longer the Primary Management Server for AGENTX” GW1 acknowledges this and stops talking to AGENTX. And I mean Completely stops talking to AGENTX. OpsMgr then tells GW2 to start accepting communication from AGENTX. OpsMgr tries to tell AGENTX that it should talk to GW2 since GW1 won’t listen. Spotted the problem? This modus operandi probably works when agents are on the same network and in the same domain where fail-over is sort of automatic. The problem we are facing now is that the server are telling the Gateway to stop accepting communications to and from the agent before the agent is notified that there is a new Gateway server to talk to. The agent will continue to talk to GW1 but will be completely ignored and you will probably start seeing events in the Operations Manager eventlog on GW1 with EventID 20000. How do I get around this little feature then? No matter if you found this article after running into the mentioned troubles or if you are googling ahead of time to be prepared, the fix is the same and consists of a few powershell scripts. These scripts are out there allready, but in different contexts, hence this post. First step: Install the new Gateway Documentation on this from Microsoft is good enough, but here’s the short version. Verify name resolution to and from Gateway server and Management Server Create certificate for the Gateway server Approve the Gateway server Install Gateway server Import certificates on Windows system Run MOMCertImport.exe on Gateway server to add the certificate into Gateway server configuration Wait