MultiPoint Services 2016 Elevated Dashboard Issue

Multipoint Services is now part of Server 2016 so we are looking to deploy it to some of our sites.

One test system on a HP ProDesk 400 G3 has been setup it seems to be running fine.

Ran into one issue today is that you need to 'Run As Administrator' for the WMS Dashboard to launch programs even though the users is in the "WMSOperators" group.

The simple solution is to change the properties on the Multipoint Dashboard shortcut in the Start Menu.
- Right click the icon in the Start Menu
- More - Open File Location
- Click 'Advanced' under the Shortcut tab
- Click 'Run as Administrator'



For the WMS Dashboard RDP file you have to do a couple of more advanced things.
Copy and save this as a .reg file and add it the MPS server.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications\DashboardExplorer]
"CommandLineSetting"=dword:00000002
"IconIndex"=dword:00000000
"IconPath"="%SYSTEMDRIVE%\\Windows\\explorer.exe"
"Path"="C:\\Windows\\explorer.exe"
"VPath"="\"C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\MultiPoint Dashboard.lnk\""
"ShowInTSWA"=dword:00000001
"Name"="DashboardExplorer"
"ShortPath"="C:\\Windows\\explorer.exe"
"RequiredCommandLine"="\"C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\MultiPoint Dashboard.lnk\""

 Edit the Multipoint Dashboard RDP file with notepad (or text editor) created from the "Save Connection settings to file" wizard in the Multipoint Manager program.
Replace the lines containing

alternate shell:s:||WmsDashboard.exe
remoteapplicationprogram:s:||WmsDashboard.exe
remoteapplicationname:s:WmsDashboard.exe

with

alternate shell:s:||DashboardExplorer
remoteapplicationprogram:s:||DashboardExplorer
remoteapplicationname:s:DashboardExplorer

You may have to change the TSAppAllowList fDisabledAllowList registry from 0 to 1.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList]

"fDisabledAllowList"=dword:00000001"

Singlewire's InformaCast LPI solution for Bells using a Cisco CME

We had been using SingleWire's InformaCast and LPI solution to run our bells schedule.
It integrated well with our Bogen equipment and allowed bells to ring both on the SCCP phones and Bogen paging system using a FXS port.

A few years ago we were installing a new CME into one of our remote sites, and found that the new version of Cisco OS was no longer compatible with InformaCast.  Or at least that is what SingleWire was telling us.

We couldn't downgrade the Cisco CME OS because the SRE module running the CUE would not work with older versions of Cisco CME OS.

After a little bit of trial and error, installing the InformaCast software using the HRE install option worked. Bells would now ring even though it reported an error about not being able to talk to the Communications Manager cluster... (see below)

Both the CUCM or CME install options for InformaCast wanted to 'talk' to the CME every time a bell was to ring and since it couldn't 'talk' to the new OS... the bell would not ring.

It's been working great until this year... now we are not sure if the Bogen equipment is starting to fail due to age or if the numerous power outages this summer have caused damage to the Bogen.  Either way the DTMF tones from the LPI software are not triggering the Bogen zones.  However paging from the Cisco CME using the same DTMF tones worked everytime.

After several tests, solutions were found for 3 out of 5 sites.  Adjusting the DTMF length and volume in the LPI device settings resolved the issue.  1 site will be getting new equipment as the Bogen is over 10 years old.  The other site will be testing this solution.

The previous config had the LPI software sending the DTMF tones based on the speaker on the single Device (ex 1410).  (Sip Address is the Voice Vlan IP of the CME)

The CME already has paging dial peers for the zones, so the LPI software will use those numbers (ex. 1411) when calling the CME via SIP calls.  The CME will pass along the DTMF codes and then the bell (aka message) will play.  (Sip Address is the Voice Vlan IP of the CME)

dial-peer voice 1411 pots
 destination-pattern 1411
 port 0/1/0 'FXS port connected to Bogen
 prefix ,07#

The problem was that the LPI device software needs at least 1 DTMF code or it will not create the InformaCast speaker.

The solution was rather simple after testing different volumes and time outs.
Change the "DTMF Via" option from "RFC2833" to "SIP INFO".
Now you do not hear the extra DTMF tones before the bell.

The other feature we lost in changing to HRE mode was the ability to play the messages on the phones.

Solution:
Create a paging group for phones (In our case all phones)

ephone-dn  200
 number 1498
 name Paging All
 paging ip 239.1.1.2 port 20482 'Works with SIP and SCCP phones
 paging group 201,202,203,204,205,206,207,208,251,303

Create a LPI Paging device that calls the 1498 via SIP.

Now create the speakers in InformaCast and add the Phones speaker to any of the InformaCast Paging Recipient Groups.  You may have to increase the "Wait Time" on the messages to allow the CME to send the DTMF tones.  The "Example Humoctopus Alert" message is perfect for testing.

 

Blocking Cyber Attacks on Windows Servers using CyberArms software and PowerShell scripts

Recently the number of audit failures on our Remote Desktop and IIS servers has increased drastically in the last month.
List of IP addresses found here.
Found this program for our 2012 servers (or any RDP using TLS)

CyberArms Intrusion Detection and Defence System

Default config...
After 3 failed login attempts, it would temporarily block the IP for 20 minutes. (Soft Lock)
After 10 login attempts, it would block the IP for 24 hours. (Hard lock)
-There is the option to hard lock the IP address forever.

Issues
1) No option to customized notification emails. -wanted to include
2) Cannot white-list a service provider only IP addresses.
3) No Response to inquiry about their products and licensing.

Since the program creates an event log for when it blocks the IP address, a PowerShell script was created to add firewall rules (permanent rules) and send email notifications out with detailed information.

The original PowerShell script just sent out emails with the server name when an event log with 4001 or 9001 is created in the "CyberArms" event log.

It worked great on our 2012 servers, however 2008 stored the Event log data with extra returns and spaces in the IP addresses.  In testing it caused the local network to be blocked via firewall.  Good thing it was a virtual machine and could still be access through Virtual Center.

Updated the PowerShell script to distinguish between 2008 and 2012 servers.

Another VBscript was created to manually delete any firewalls from 'trusted' IP addresses using netsh from another computer.

After the first weekend having to check each IP address and manually delete the rules got old and time consuming.

The next revision of the script added NSlookup to a ProviderLookup function in the script.

The ProviderLookup function was created to allow certain IP addresses or provider names (provided by NSLookup) to be unblocked automatically.

Example if NSlookup returned a provider name with "Domain.ca" in it, then we trusted it and the firewall was deleted.

Emails now include the IP address, the provider information and if the rule was deleted.

Steps...
Install CyberArms software
Enable any security agents in CyberArms
Download PowerShell Script "CyberArms Eventlog Script.txt"
- Rename to .PS1 and change "DOMAIN.CA" and email settings.
Create Task Sequence to run the script when event 4001 or 9001 is logged.

Update - April 21, 2015

The ProviderLookup function will now include Country and ISP information extracted from http://ipaddress.com if it cannot find a DNS name for the IP address.

Future options
1) Create the same firewall rule on more that one server via PowerShell Array variable.
2) Create a pause between rule creation and rule deletion, just in case there was malicious intentions.
- probably use a ping command to 127.0.0.1 for 10 minutes then have it delete the rule.

3) Working on cleaning up the ProviderLookup function so that certain ISP names will be allowed.