VQ has always operated in a distributed manner; we have team members located around the UK and a central office. We’re about 90 minutes west of London with our closest big cities being Bath and Bristol. It’s a great place to live; low density and plenty of green.
Following advice from the UK Government, we have now moved to a full home working mode.
I want to keep this blog simple; we’re here to help. We’ll be making more announcements and issuing advisories on how to optimise VQ for increased workloads.
What we’re announcing today is that we’ll make free licenses available to existing customers who need to increase their VQ Conference Manager capacity or install more instances of VQ Conference Manager. When the crisis is over, we’ll revert back to the original licensed VQ capacity.
If there other ways we can help, please let me know.
Stay safe
https://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.png00mikehttps://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.pngmike2020-03-23 07:55:002021-02-01 09:50:42Coronavirus (COVID-19) - Business Update from VQ
(This is the second part of the documentation, and it is built on what is explained in the first part. Click here to read part 1)
Objectives of this blog post:
Describe the steps to follow to detect a condition and then generate a mail/message with links to dashboards. Those can be configured to display different time periods, and in this case, it is a 10 minutes window centered on the triggering event. The example contains a single dashboard; it could, however, contain many and each dashboard might contain many visualizations – the key concept that all of the data required to support any analysis of the event trigger is delivered to whoever needs to look at it. For example, rather than an email, it could be pushed to Teams, Slack or Service Now.
Step 1: Create a
dashboard that displays relevant data
First of all, you need to create a Kibana dashboard that
will display the information you want to see once the watcher alert is
triggered. Then, through the watcher actions, we will adjust the time range to
focus on what happened around the moment the error was found.
Once you have created your dashboard and added the
components you desire, make sure the time range is on absolute mode. You then
need to copy the URL of the dashboard from the address bar in your browser, and
save it somewhere. It should contain a part that looks similar to this, and it
is what we will modify in the watcher:
In order to replace the timestamps used in the URL by the
ones retrieved from the Kibana search, we will need to modify the structure of
the watcher to utilize variables. We will transform the payload (result of the
watcher searches) to create a new one containing the data we want to use in the
Email action.
We have now defined a time range that starts 5 minutes
before the moment the watch was triggered, and ends 5 minutes after it was
triggered.
After this operation, the newly transformed payload contains
an array of values (defined in items), and those can be acceded by using ctx.payload._value.{index_in_array}.
The transform block is executed after the search (after the
first payload is created), but before any other actions. Therefore, we need to
update the previous references to the payload in order to use the new ones.
Step 3: Utilize the new payload data
After the transform, we have an array of data containing: {firstSearchHits,secondSearchHits,fromTime,toTime,firstErrorTime}
We can now replace the previous references to the payload
data. In our case, it concerns the Email Action condition, and the information
returned to the user in the email.
(note: In the painless scripts, you access the values
in the array by doing _values[index]. In the rest of the watcher, you have to
use _values.index. In both cases, the index starts at 0)
In the body of the email, we can now include useful data
easier, for example:
“text”:
“The watcher has detected CDR Connection Failure errors. The first error
happened at: {{ctx.payload._value.4}}\nThere are {{ctx.payload._value.0}} hits
in the first 30s after {{ctx.payload._value.2}}, and {{ctx.payload._value.1}} hits
in the 30s period before the search.”
We can also include the previously created dashboard URL, by
modifying it with the new values. The change should look like this:
(note: It is currently impossible to create a shorter
version of the link)
The email received by the
user should look like this, and contain a link to the dashboard displaying the
correct time range:
https://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.png00Escobar Munoz Thomashttps://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.pngEscobar Munoz Thomas2020-02-24 08:59:002021-02-01 09:50:46How to setup a watcher to link to a dashboard in Kibana (Part 2/2)
Describe the steps to follow to configure and create a simple watcher that detects a condition and sends an email when triggered. This document focuses on a real user case, the monitoring of CDR Connection Failure errors, which can be used as an example and base for different applications.
The watchers are part of the Elastic Stack subscription
license, and therefore it is needed before doing any alerting.
Step 2: Set up notifications
When the watcher triggers, you can choose to add an action
to send a notification that an event was fired. You can then precise the
message you want to send, but first, you need to setup the notifications.
You need to create a webhook for your slack system. Follow
the steps described in the link above (you need administrator privileges). Once
that is done, go to the “Dev Tools” tab and input the following request:
“text”: “One of your watches generated this
notification.”,
“mrkdwn_in”: “pretext, text”
}
}
}
}
}
}
}
Step 3: Create the watcher
Go to the Management>Elasticsearch>Watcher tab, and
create a new watcher.
You can use the simple “Create Threshold Alert” option, and
choose the action you want to link to the alert created.
You can also use the “Create Advanced watch” option, where
you can customize more in detail your watcher.
Recommendation:
The window provided by the Kibana page to edit the watcher is really small and inconvenient. It is highly recommended to use software to edit the watcher that can display .json files properly. It is preferable to have an editor that can manage the indentation and color the text for better readability. Those can include: text editors (ex: notepad++) or IDEs (ex: Visual Studio). You can then edit the file in your editor with ease, and paste it back into the Kibana window to save it.
Here is a complete example of a watcher that tracks CDR Connection Failure errors every 30 seconds, by detecting the first time the error occurs and sending an email with the time it was detected:
In this case, the CMS server produces an error if the CDR receiver cannot be reached. This happens every second until the problem is resolved. We want to set up a watcher that triggers the first error but doesn’t continue to send notifications after the first one.
In order to do so, this watcher uses chained searches:
The first one searches through the logs in the time range [now-60s ; now-30s] to make sure no new logs are missed. We verify that at least one error is found, but less than 30, which is the maximum number of errors over that period (1error/s). This is to avoid triggering the action multiple times after the first detection of the error if the error keeps being sent regularly.
The second search uses the time range of the previous iteration of the watcher, so in this case 30s earlier [now-90s ; now-60s]. The second search is used to verify if the error was already present 30s before the current search. If it is, it has been handled already and we do not need to send another notification.
Here is the “painless” script that defines the condition to
decide if we send a notification email or not:
https://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.png00Escobar Munoz Thomashttps://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.pngEscobar Munoz Thomas2020-02-23 08:38:002021-02-01 09:50:52How to set up a watcher to detect CDR Connection Failure errors in Kibana (Part 1/2)
We’ve released 3.3 today and it’s now available for download from vqcomms.com.
3.3’s significant in that it demonstrates the value of some of the decisions we made on the 3.x platform. The adoption of a standards based authentication process based on a best of breed Identity Server which was, in turn, enabled by our decision to move to a Kubernetes architecture based on containers meant that the reality of getting ADFS to work was far less daunting than it might otherwise have been. It turned out to be surprisingly easy; we had to make a very small code change.
Adding a Jabber Add-in is the same; we were able to repackage a lot of what we have for the Outlook Add-in. So…..if you have ideas on adding conference control to other applications or services that support a browser based UI, please drop me a mail.
The UI changes might appear small but they’re the pre-cursor to what happens next….lots of work under the hood and we’ll now slowly start introducing new functionality and coolness. The big one planned for 3.4 is participant move and following that, pane placement.
Other cool stuff that you don’t really see are things like use of Ansible (https://www.ansible.com/) which is significantly helping and makes some of the complicated stuff that’s required for High Availability in future releases possible. Anybody who’s interested in Ansible, please also drop me a mail.
So, 3.3, another really good step forwards. Enjoy.
2019 has been quite a year for VQ. Our relationship with Cisco has continued to develop and we’re really looking forward to working more closely with Cisco in 2020.
I’m incredibly excited about
where we are with the product; 3.2 is stable and working well hosting customer
workloads. The success of the product is winning new customers and opening a
range of new opportunities.
Here in the labs at VQ
Towers, we’re starting to see signs of life for some seriously cool
functionality heading towards the door marked ‘customer’. High Availability
(‘HA’) has been a goal for a long time; we’ve had ‘warm standby’ and then
during the 2.x and 3.x years, ‘no standby’. Well, the great news is that HA is
coming your way; the multi-year investment in advanced stuff like Kubernetes
has meant that in the relatively short time since Summer, we’ve managed to
configure and test a first-generation HA architecture. A three node HA cluster
with integrated load balancer has just completed a 9.6 million call test that
ran for just under 12 days running 24/7. The test features 2000 participants
repeatedly joining and leaving calls. It simulates about 10 times the call
volume per day of our biggest systems in the field. We were rather disappointed
because it should have run to 10 million calls but failed because a network
blip caused a fail-over event that the test tool didn’t contain and stopped.
VQCM handled the issue perfectly. We still have work to do to wrap-up packaging
so it’s easy to install and update but then we’ll make it available as an
‘Experimental’ 4.0 version for customers to get their hands on and start to
prepare for. Dates to be confirmed but expect to see more on HA in Q1.
The other feature we’ve been talking about for a long time is Recurring Calls; they missed the cut back in 2015 for the ‘self-service’ focus of 2.x and have been absent ever since. They’re now wired up at the 3.5 platform level and next-up is adding a UI. All on a modern, state of the art architecture that’ll scale.
Activity 2 is making
progress; in its first form it’ll include Participant Move and Pane Placement.
Activity 2 and Scaling are yielding some very interesting possibilities which
are being validated and have the potential to be fairly impactful. Dynamic
Space Templates are coming; change the Space Template and all Spaces based on
the Template change immediately…
Our investment in an advanced architecture is starting to enable some of the functionality we hoped it would and have spoken about; it’s now becoming real and looks great!
Finally, a big thanks for all of your support in 2019. Have a very happy Christmas and we look forward to seeing you in 2020.
Regards,
Mike Horsley
https://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.png00Mike Horsleyhttps://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.pngMike Horsley2019-12-11 13:11:252021-02-01 09:51:01Reflecting on 2019 at VQ Communications
I’m really pleased to announce that VQ Conference Manager 3.2 is now available for download.
3.2’s an exciting release because of what’s in it and, moving forward, what it enables.
What’s in it? Lots of refinements:
The data written into Elastic and been restructured to make it easier to produce visualizations. Goodness like CMS Alarms are now available. We’ve updated all the Visualizations and Dashboards.
The Outlook Add-in now caches the login name so users don’t have to repeatedly type it in (passwords are still required in non SSO mode)
We’ve added support for Cisco Duo to the list of supported SAML2 providers.
The Blast-Dial app now includes an optional “press-1 to join” message when each of the Blast-Dial recipients receives a call.
CM-Admin refinements; changed certificates and Outlook Add-whitelists in SAML2 mode (to name but 2).
Bug fixes to the Call CoApp. Placing outbound calls from an inactive Space now works consistently.
The LDAP Configuration page has been cleaned up and restructured into a page with 3 tabs; much easier to use
The Bulk-Emailer contains a second template that includes functionality to auto-configure the iOS app. Very cool.
Bug fixes
What it enables:
One of the big ‘under the hood’ changes is upgrading Kubernetes to the latest version (1.15). 1.15 includes the Beta High Availability (“HA”) support. Please note that this is not VQCM High Availability at 3.2; it’s the enabler that will (should) enabled HA in the next release of VQCM (3.3; due Q4/2019).
With the Elastic data restructuring just about complete, we also plan to enable syslog ingest in 3.3 (due Q4/2019) which we’re also really excited about. The goal here is that we’ll be able to save syslog data in Elastic and, by doing so, be in a position to include CMS/VCS logging as part of the data contained in visualizations/dashboards.
More information is available in the release notes which are available for download from vqcomms.com. Please ensure you select version 3.2.
A few weeks ago, I had the opportunity to visit a brand-new customer we’d recently won in Geneva. The request from them was some on-site assistance and consultancy with installation and configuration of VQ Conference Manager. These kinds of professional services are not something we do a lot of; we simply can’t scale to provide them to all our customers and we already have a growing network of highly skilled and trained partners quite capable of performing these functions.
However,
our transacting partner in this case wasn’t quite fully up to speed and I
hadn’t been to Geneva for a while, so I decided to volunteer for the trip:
Switzerland is a lovely place to visit this time of year.
We’re seeing a large number of customers who are migrating video conferencing services from legacy Cisco MCU (formerly Tandberg/Codian) infrastructure to their new Cisco Meeting Server estate. A request I often get in pre-sales product demonstrations for VQCM is, “Can you make my CMS work like my Codian used to?” And this customer in Geneva also fell into this category.
The
old MCUs are hosting a set of permanent conferences, one for each of their
meeting rooms. The idea being, once you have reserved a particular room, by
definition you have also reserved that conference. Creating permanent
conferences (or ‘Spaces’ in CMS parlance) is of course bread-and-butter for
VQCM and CMS, so this part of it was completed in very short order.
But
in this case, not only could we replicate the existing service, we could
actually enhance it. VQCM’s ability to easily create multi-role Spaces via its
Space templates meant we could create a different dial-in and in-conference
experience for the hosts and guests. The hosts can dial a short dial code and
enter the Space without being challenged for a PIN. The use of a couple of dial
rules means that guests have to dial the full code and are required to enter
the PIN before entry. We were thereby able to meet a requirement for quick easy
access to the Spaces for internal users but added security for external
participants.
It’s
always interesting to see VQCM working its magic in live, customer
environments. Especially when I see with my own eyes the benefits it brings now
and the enhancements it makes possible in the future.
https://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.png00Barry Pascoluttihttps://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.pngBarry Pascolutti2019-05-14 10:46:212019-05-14 10:46:23Visiting customer site in Geneva
3.1 is available for download from vqcomms.com; there’s a sense of relief here at VQ Towers that we finally delivered it. A huge amount of work went into 3.1 and it represents another big step forward. Some of the functionality might be described in small words (for example, Single Sign-on or “SSO”) but behind the scenes a lot of work went into getting the Open Id Connect (“OIDC”) Identity Server up and running; not only do we get SAML2 and Windows Authentication with it, we can also now authenticate with services such as Google. It’s been quite an eye-opener to get exposed to state of the art authentication and the services provided by companies such as Okta (and their partners, JAMF and Yubico). From a technical perspective, I must admit I also found it remarkable how clean the mechanisms are and how, for example, access tokens are cryptographically signed and the consuming software can use the “time to live” value to know when the token expires. Very neat.
3.1 is an example of what is possible
because of the architectural decisions we made for the 3.x platform; the OIDC
certified Identity Server is hosted as a Container and is packaged as part of
the VQCM 3.1 VM. Reactive Calls (aka Blast Dial) is another example of what’s
now possible; it’s packaged as a small service that sits on the message bus and
responds to events generated by the VQCM core.
I start this blog with an apology. It’s been over week since
I returned with my colleague Barry Pascolutti from a whirlwind trip to the USA.
Since Cisco announced at the SEVT earlier this month that customers deploy CMS
with VQ Conference Manager we have been inundated with Cisco, Partners and now
customers wanting to know more about how to enable the service model they need
for their users.
But I digress. We had been invited by our partner WWT to an
exclusive event in Tampa to present and meet with 180 Federal customers. Barry
and I joined the team from WWT and ran back to back demos and had many
discussions with both customers, Cisco and potential clients. In addition to
features such as Single sign-on and Blast dial/Reactive calls, it was
interesting to hear the need for simple user tools like the Outlook Add-in/Plug-in,
and of course the comprehensive Analytics for the Ops teams. It’s clear that
Federal users typically experience constant turnover of staff due to deployment
demands, so simple, out of the box tools are essential.
Then a short hop up to Washington DC and a major
presentation at the Cisco Herndon office. Not a lot we can share, but the
customers have some major CMS projects, and after a stellar demo by Barry and
some intensive technical questioning, we believe we may have un-blocked a
couple of major projects. Whilst in the building we then ran to another meeting
room to join an internal Cisco webinar session called “Know your Stuff”; the
audience being internal Cisco and wide ranging in their responsibilities.
So what did we learn? I start many of presentations in the
USA stating we are two countries separated by a common language. That wasn’t
the case when we got into how VQ Conference Manager and CMS enable the services
users want.
Frankly CMS and VQ Conference Manager rocks.
https://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.png00Gileshttps://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.pngGiles2019-03-25 13:52:492019-03-25 14:02:13Giles & Barry’s Great American Adventure
We’re increasingly thinking of VQ
Conference Manager in terms of it being a platform that enables UC problems to
be solved. With the base functionality stable and delivering really big
workloads, we’re now starting to introduce more of what we’re calling “UC
Apps”. These sit outside the VQCM web user interface and were designed to make
it easier for end users to make more calls because they have higher degrees of
control or simply because we made it easier for users to join calls.
With 3.1 heading towards beta status, we’ll be introducing the following new apps:
Outlook plug-in
iOS phone app
Blast Dial (also known as Reactive Calls)
These join the Outlook Add-in launched with the initial version of 3.0. The UC apps get even better in 3.1 for customers with Single Sign-On because the UC Apps also support SSO! No more having to remember passwords and one less barrier to adoption.
Blast Dial is headless for 3.1 in
that it does not have a user interface; you configure it via a config file.
Blast-Dial allows a Space to be defined where if somebody calls into the Space,
the Space automatically calls out to a predefined list of attendees. Ideal for
use in environments where a team needs to respond to an event.
A variant of the Outlook Add-in we’re
playing with at the moment works with Google G Suite. Again, it’s enabled
because VQCM 3.1 supports Open ID Connect “OIDC” which is the authentication
protocol used by services such as Google. I’ll keep you updated on how that
particular skunk project unfolds.
Behind the scene, more are coming. What’s also interesting is how a further subset of “utilities” or tools are evolving to meet customer requests to solve problems they face. These typically are run from a command line and use VQ’s REST API; they solve problems customers are facing in a tactical manner – we can get them done quickly because they sit outside the core VQCM product. Here’s a couple of examples:
SetSpacePin; a command line utility that works with a customer’s PowerShell scripting. The PowerShell script listens on an Exchange mailbox and allows users to request details for their Space or send a calendar request to an Exchange mailbox; if the calendar request contains a specific keyword, the PowerShell script calls the command line tool and sets the Pin/Passcode on the User’s Space. It’s a concept at the moment and the jury’s still out on whether the customer will deploy it. Initial feedback is positive.
Another example is from last week; a customer would like to enable streaming on specific Spaces and set the Streaming URL. We’re putting together a small utility that’ll allow their operators to do this and therefore avoid the pain of doing it via the Postman API.
Having said all that, I do need to
set the correct expectation. VQCM 3 is enabling us to start thinking in terms
of a platform and UC Apps. Our APIs are not yet public; they need a lot of love
to iron out inconsistencies and they’re not documented. Work is underway to
address that (and it looks pretty nifty) but it’s going to be some time before
we go public with it.
If this blog has triggered any thoughts about what UC Apps (with or without UI) that you think would help solve a UC problem you’re experiencing, please drop us a line.
https://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.png00Mike Horsleyhttps://www.vqcomms.com/ahomteej/VQ-Logo-LS-Transparant.pngMike Horsley2019-03-12 08:08:232021-02-01 09:51:19VQ's Growing Number of Unified Communications ("UC") Apps
