Cannot connect to Core Hyper-V Server 2012 R2 with RDP

So i was thinking to add a new Core Hyper-V Server 2012 R2 to my network at home based on a workgroup and configure it with RDP after enabling the Remote Management and Remote Desktop from the console. That’s a no go by default… What do i mean? it turns out Core Hyper-V Server 2012, and Core Hyper-V Server 2012 R2 have their firewalls on by default and configured to drop everything from the public profile (all rules are disabled)
The Startup menu of the server does not change these profiles to allow RDP traffic in (it only allows the Domain and Private profiles to allow the RDP traffic)
So how do you enable these rules?

1. Configure the Firewall locally from Command line
2. Use CoreConfig tool for Server core 2012

The First one requires you to log on locally to the Core Hyper-V Server 2012 and use the PowerShell to enable these Firewall rules.
it is done this way:

Set-NetFirewallRule -DisplayGroup “Windows Firewall Remote Management” -Profile Public -Enabled True

The configuration with CoreConfig is done with a GUI. just download the source and copy it to a local folder on the Core Hyper-V Server 2012. start PowerShell from the command shell by typing: PowerShell after the Prompt. browse to the folder in which you copied the CoreCofig files and .\CoreConfig.ps1.

Now simply browse to the Control panel:



Click on the firewall settings



And enable the Remote Desktop rule (the active Firewall profile (Public) is selected by default)



That’s it, see you next time.

Using Nagios++ Agent for Monitoring Windows Systems (Part 3, managing the client)

In the former post the Nagios++ client’s architecture was shown as well as its installation concepts. In this post i will elaborate some more on the installation of the Nagios++ agent and from there on explain the way the Agent will be managed from installation perspective

To summarize the Nagios++ Agent configuration three components make up a monitoring node:

1. .ini file(s)
2. Nagios Management engine
3. Supporting classes and modules

The management engine is installed with a Microsoft installer file (.MSI) the way installations like this are done is very straight forward. the only prerequisite for an .MSI installation to work  is the availability of Microsoft Installer framework. the actual command line for the installation is as follows:

msiexec /i "NSCP-0.4.2.58-x64.msi" INSTALLLOCATION="C:\Program Files\NSCP" /qn /l* %TEMP%\install_nagios_agent.log

When the engine is installed the supporting .ini file(s) and classes must be installed. this is a very straight forward process of copying files from one central location to the managed node.

The Modules and scripts directory are the places in which all additional modules and scripts respectively have to be placed.

The ini file is the main configuration of the Nagios Agent. The configuration of it is very well covered in many posts, look at them if you will here, here

In short the list of allowed hosts will configure the partners to which the Nagios agent will talk. modules defines the modules which are allowed to do checks on the monitored node, Aliases are checks being done by the Nagios agent with the aid of the allowed modules.

The main challenge

So when all agents are in place on the monitored nodes the main challenge is the maintenance of the set of scripts, plugins and off course the ini file(s) themselves on the nodes. let me clarify this a bit more:

Because of the nature of monitoring (collecting lots of counters from hosts) the monitoring aspect of a large number of hosts can become problematic. Counters will have to be bundled to sets of counters which themselves do represent a function or service of that device. Furthermore with monitoring large clients with, so called, chains. a group of monitored nodes must be configured in such a way the individual node status reflects its place, function and weight in the chain.

In short: the .ini file on a monitored node will reflect its place in the monitoring process of that client. By now i think you can imagine the generation of specific .ini files for specific groups of nodes will require a system that can manage and maintain all these aspects of the generated .ini files.

 

What .ini files will have to be generated

For monitoring of chains and clusters, specific checks will have to be done on the target nodes. for instance: in a SQL cluster of 3 nodes; certain checks targeted at cluster services and SQL processes will have to be added to the .ini file that will be copied to the cluster nodes. Likewise .ini files will have to be generated for Mail servers etc.

How should this management system manage the configuration of all these .ini files?

The system should be able to do configuration management in all its aspects concerning .ini files and supporting modules, classes and scripts.

1. A central Template .ini file should be maintained by the system, in this case it means the system must always have a reference .ini file and leave it untouched
2. All available modules must be catalogued, for each modules its use to what systems or functions must be known
3. All available classes must be catalogued, for each class its use to what systems or functions must be known
4. All available scripts must be catalogued, for each script its use to what systems or functions must be known
5. for each module, class and script its use must be inventoried
6. All monitored nodes must be known in this system
7. For each monitored, node mappings must be available to its used .ini file, modules, classes and scripts
8. The system should be able to generate a new .ini file with a single action based on the reference ini file and its specific modules, classes and scripts
9. The system should have an inventory of each node, its deployed ini files, modules, classes and scripts as well as its individual versions.
10. The system should be multi tenant
11. The system should be able to host multiple sessions simultaneously
12. The system must have redundancy and recovery features
13. The system must have a connector to the used software distribution systems so it can deliver the content directly to the right software distribution collection
14. The system should have a management interface, which supports Role Based Administration, in which administrators can manage the monitoring configuration of their own clients and/or sites.

When all these items are covered you will be able to manage and maintain the monitoring of multiple clients and sites. In this way delegation of administration is also possible.