Tag: Script

2014

Mikrotik

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

2012

MicrosoftOpsMgr 2012

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. 😉 Being a slight modification of the script in the last post I am not going to go through those details. Use that post if you need references to the Inputs, the OpsMgr 2012 Modules, Management Group connection and gathering your agents and management servers. Why Is It Faster? We are doing the same thing, on the same agents and with the same servers. And we already did some optimization by loading them all into memory and working from there. How do you make it faster? Basically, I’m cutting the over-head of the cmdlets and how they work. You may have noticed that in the “Do Stuff” section, we are actually calling the Set-SCOMParentManagementServer cmdlet twice! Once for the primary Management Server and once for the fail-over Management Servers. In effect, we connect, fire a command, wait for result, and disconnect two times for each agent. And pretty much only because the cmdlet does not offer support to set primary and fail-over management servers at the same time. Any attempt to do so will return an ambiguous parameter error. I don’t like that. A brief look at the agent object class, Microsoft.EnterpriseManagement.Administration.AgentManagedComputer, revealed a method called SetManagementServers. This method takes, or actually “requires”, two parameters. One for primary and one for fail-over management servers. Yay! Using this method saves us a bunch of over-head and a couple of round-trips to the SDK-service. The Challenge

2011

MicrosoftOpsMgr 2007

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. 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! DisableACSForwarders 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: C:\..\Scripts> .\DisableACSForwarders.ps1Root Management Server: rms.teknoglot.localACS Forwarder name (wildcard): *.teknoglot.local

2010

MicrosoftOpsMgr 2007

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

2009

MicrosoftOpsMgr 2007

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

MicrosoftOpsMgr 2007

NetworkAdapterCheck.vbs fails on Windows 2000

Problem Here’s my summary of the problems with the NetworkAdapterCheck.vbs script in the Windows Server 2000 Operating System Management Pack för Operations Manager 2007 that is causing the failed to create System.PropertyBagData error i wrote about earlier. This information in also available on https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=432627&SiteID=446 Symptoms This “research” comes from getting an obscene amounts of Script or Executable Failed to run in the Operations Console. Each time it was the NetworkAdapterCheck.vbs script that could not create PropertyBagData. The error message copied from one of the alerts looks like this: The process started at 14:29:26 failed to create System.PropertyBagData, no errors detected in the output. The process exited with 0Command executed: "C:WINNTsystem32cscript.exe" /nologo "NetworkAdapterCheck.vbs" MASKEDCOMPUTERNAME 0 false true falseWorking Directory: C:Program FilesSystem Center Operations Manager 2007Health Service StateMonitoring Host Temporary Files 2882781One or more workflows were affected by this.Workflow name: Microsoft.Windows.Server.2000.NetworkAdapter.NetworkAdapterConnectionHealthInstance name: 0Instance ID: {F4C478D3-38E5-8C29-3957-E3B7F486216E}Management group: MASKED This error repeats almost as often as the script is scheduled to run and appears on almost every Windows 2000 server. Probable Cause I am not really sure, but after a quite a bit of troubleshooting I am pretty sure it all boils down to a malformed WMI-query. What I basically did was to extract the script from the MP and dry-run it to see if I could find anything obvious, which I didn’t. Since I didn’t have a good debugging too available, like in PrimalScript, I added the VBS equivalent of old-school printf debugging. I basically added wscript.echo "Line XX:" & Err.Number

MicrosoftOpsMgr 2007

Clearing Disabled Discovery in OpsMgr 2007

Jonathan Almquist has posted (a while ago) an article on how to clear discovered objects after you have disabled the discovery rules in OpsMgr that I think deserves a notion. Read more about it at Jonathan Almquist on Operations Manager : Remove-DisabledMonitoringObject.

2007

CodeVBS

w3Socket in VBScript

I’ve been doing quite a lot of VBScripting in a couple of projects lately. The current one requires med to connect to a couple of telnet servers and look for… stuff. Since we’re not in VB6 och .Net i cannot simply user Winsock as normally due to the lack of licensing features in VBS/WSH. Thankfully for me, Dimac has release a nifty little component for free that makes talking telnet in VBS very simple. I thought that, hey! I must share this! So here’s an example in Classic VBS: Dim oTelnetoTelnet = CreateObject(Socket.Tcp)With oTelnet.DoTelnetEmulation = True.TelnetEmulation = TTY.Host = 192.168.242.1:23.Open.WaitFor SLUSSEN login:.SendLine ANiftyUsename.WaitFor Password:.SendLine [email protected] ~ #.SendLine ifconfigMsgBox .Buffer.CloseEnd WithSet oTelnet = Nothing Not very hard at all. This one is connecting to my router (with fake user/pwd… DUH!) and there’s no support for setting the prompt type there, thus the “~ #”. The result of running this script with correct login info gives me a popup with the routers NIC-configuration.