Azure’s Advisor

index

Do you know “Azure Advisor”? Do you know how useful it can be for your Azure environment?

What is Advisor?

Advisor is a personalized cloud consultant that helps you follow best practices to optimize your Azure deployments. It analyzes your resource configuration and usage telemetry and then recommends solutions that can help you improve the cost effectiveness, performance, Reliability (formerly called High availability), and security of your Azure resources.

With Advisor, you can:

  • Get proactive, actionable, and personalized best practices recommendations.
  • Improve the performance, security, and reliability of your resources, as you identify opportunities to reduce your overall Azure spend.
  • Get recommendations with proposed actions inline.

You can access Advisor through the Azure portal. Sign in to the portal, locate Advisor in the navigation menu, or search for it in the All services menu.

image

The Advisor dashboard displays personalized recommendations for all your subscriptions. You can apply filters to display recommendations for specific subscriptions and resource types. The recommendations are divided into five categories:

  • Reliability (formerly called High Availability): To ensure and improve the continuity of your business-critical applications.

  • Security: To detect threats and vulnerabilities that might lead to security breaches.

  • Performance: To improve the speed of your applications.

  • Cost: To optimize and reduce your overall Azure spending.

  • Operational Excellence: To help you achieve process and workflow efficiency, resource manageability and deployment best practices.

image

Now let’s check out the Recommendations for my tenant. Click on “Recommendation” section to check the environment.

Here you can select which subscription to run the Advisor, then choose what type of recommendation you would like to view (That is, in isolation), or click on “All recommendations” on the left side of the above screen.

In my test environment he identified 24 issues in total, 8 x “High impact”, 10 x “Medium impact” and 6 x “Low impact” for security.

As the Advisor warned that the issues are critical, we can click on “Security” and check the description of the vulnerability and if applicable, apply the solution recommended by the Advisor itself.

image

Now you can click on the vulnerability pointed out and check which resources are impacted and the solution suggested by the Advisor and apply it if it is appropriate for your environment.

image

image

In the examples above, you can see that the Advisor provides a description of the vulnerability and what steps are taken to resolve the issue.
It is interesting that if you click on the option “Quick Fix Logic” the Advisor will provide you with a json script to solve the issue

That and everything for today guys, see you soon!

Cisco CUCM – SOAP Overview

Hey guys,

Today I’m going to talk about SOAP AXL. A powerful and useful type of communication model. Most of the Cisco Unified Communications Manager (CUCM) APIs are exposed via SOAP-based XML Web Services.
I’ve been using it to create some Dashboards for CUCM!

The Administrative XML Web Service (AXL) is a XML/SOAP based interface that provides a mechanism for inserting, retrieving, updating and removing data from the Unified Communication configuration database.
Developers can use AXL and the provided WSDL to Create, Read, Update, and Delete objects such as gateways, users, devices, route-patterns and much more.

SOAP provides an XML-based communication protocol and encoding format for communication. For example, to describe a phone using XML, you would define the following structure.

image

Now, how do you know what types of requests you are allowed to make, what types of data those requests require, and what type of response you expect to receive?
This is where the Web Services Description Language (WSDL) comes into play. A WSDL file (along with any associated XML schema files) can be used to fully describe the capabilities of a SOAP API.

Luckily  CUCM provides a WSDL file for each of the SOAP-based APIs it supports and there are tools to read WSDL files and then make the SOAP API service methods available easily. The eventual goal is to leverage a programing language such as Python (I’ll cover that in future posts) to interface with the various SOAP API’s, but it helps to manually explore the API using a visual tool that can understand the WSDL file. One of these tools is SoapUI, and you can download it from here HERE.

Let’s see now step by step how to use SOAP and send some requests.

Step 1 – Download the AXL API WSDL File

The CUCM AXL API WSDL file is published on the CUCM server itself, as part of the Cisco AXL Toolkit plugin.

  • Access your CUCM
  • Navigate to ApplicationPlugins and click Find
  • Next to Cisco AXL Toolkit, click Download. The file axlsqltoolkit.zip is downloaded.
  • From your Downloads folder, extract this downloaded file (right-click Extract All…) to the default location (should be in the Downloads\axlsqltoolkit folder)
  • Once extracted, in the schema folder you will notice there are a number of folders. These are for various older CUCM versions. For this lab, we are interested in current. That folder contains the current CUCM’s AXL WSDL (AXLAPI.wsdl) and schema (.xsd) files.

Step 2 – Start SoapUI

Now you can load this WSDL into SoapUI, get things configured, and start sending queries. Follow these steps to load the WSDL into SoapUI.

  • Launch the SoapUI application.
  • Close any open Endpoint Explorer or other windows that may show up when launching SoapUI.
  • Click FileNew SOAP Project

image

  • For the Project Name enter UCMSOAP
  • Below that field, for the Initial WSDL file, click Browse. Navigate to your current AXL WSDL file extracted earlier:

Step 3 – Run an AXL Request from SoapUI

Once the API is loaded, you must set some of the default parameters, specifically the CUCM hostname or IP address and the credentials so that they don’t have to be re-entered for every query.

  • In SoapUI, in the Navigator pane on the left, you’ll see the new project folder named UCMSOAP and the AXLAPIBinding object. Right-click on the AXLAPIBinding and click Show Interface Viewer (same as double-clicking or pressing Enter).

image

  • In the AXLAPIBinding properties, select the Service Endpoints tab.

image

  • You’ll notice the Endpoint is set to https://CCMSERVERNAME:8443/axl/ (with blank username and password)
  • Double-click on CCMSERVERNAME so it can be edited and replaced by the hostname of your CUCM. Press Enter
  • Double-click on the Username and Password to enter the credentials. Be sure to press Enter for the field to be saved.
  • Close the AXLAPIBinding window by clicking the X in the right of its blue title bar .

So now SOAP is all set up and ready for issuing queries.
I’ll give you now an example of how to do that.

For example, a basic thing as getting the CUCM Version:

  • Choose AXLAPIBinding
  • Scroll Down till getCCMVersion. Expand it and you will find Request 1.
  • Double-click to open it, and you will find its XML Request.

image

You will observe there is a ?  in the processNodeName field. When a new request is created for an operation in SoapUI, all available options are presented, so there are often many that either need to be removed or filled in with valid data (instead of the default ? placeholder).

So, remove it, and click in the green button to send this request. The Response will show up at right:

image

You have successfully sent an AXL/SOAP request to CUCM and received a valid response!!
From now on you can start playing with other types of requisitions, like add, update or delete.

Enjoy it Smile

Bruno

Azure’s Auto-Shutdown

auto-shutdown

Hi folks,

Today we’ll talk about how to set up Azure Auto-Shutdown through the Azure portal.

This feature allows the machine to be programmed to shut down every day at the same time if you turn it on at some point throughout the day. Also, through the Auto-Shutdown you can configure a “Webhook” to notify the VM shutdown.


But what does “Webhook“ mean?

WebHook is a concept called “Web callback” or “HTTP Push API”, it is an application to provide other applications with information in real-time. The webhook provides data for other applications, meaning that you get data right away. Unlike typical APIs where you need to search for data very often in order to get it in real-time.

How to Configure Auto-Shutdown

To configure go to your virtual machine, in the Operations bar click on “Auto-Shutdown”.

image

Now we are going to add the time that the VM will be turned off, the Time Zone of your region and if you have any Webhook or email click on “yes” to add it then click on “Save“.

image

All done! My virtual machine is set up to shut down through Auto-Shutdown.

image

That’s all for now guys, see you then!

Cisco Finesse – Disconnection Problems

Hi everybody,

Today,  I’m going to give you a troubleshooting tip about an issue I’ve been facing, on Cisco Finesse.

Agents started complaining that they suddenly get disconnected, and when you see the reports on CUIC, the reason is Connection Failure.

For this case, we are using Cisco UCCX 11.6.2.

First of all, we have to check the Layer 1. Make sure the phone is not losing connection due a cabling faulty.
If you are using Jabber, make sure you network connection is stable, and if it’s VPN, your internet is stable.
Voice traffic is really sensitive, so any minimum interruption can cause a disconnection.

Another thing Cisco recommends is, if your agent has Deskphone and Jabber configured with the same line (but not using at the same time, as UCCX does not support shared lines), you have to keep only one added to the End user and to the Application user. If you have both, it work, but you will have that disconnection some times as well (yes, I faced that in the past).

Now, the latest I’ve heard from them!

As per this Troubleshooting, these presence driven logouts occur when UCCX does not receive presence available status from the agent PC/browser.  The system logs the agent out after 60 seconds.

So, seen all this points, there are 2 more difficult things to be caught, and I recently came across.

  1. Browser.
    Chrome v88+ and Edge are known to cause these issues.

    For agents logged out with the tab minimized/backgrounded:Disable Automatic Tab Discarding:
    For versions 75 and above: Add chrome extension ‘Disable automatic tab discarding’https://chrome.google.com/webstore/detail/disable-automatic-tab-dis/dnhngfnfolbmhgealdpolmhimnoliiok
  2. IntensiveWakeUpThrottlingEnabled Starting with Chrome 88: Improved resource consumption for background tabs To save on CPU load and prolong battery life, Chrome will limit the power consumption of background tabs. Specifically, Chrome will allow the timers in the background tabs to only run once per minute. If agents are using Chrome v88+, navigate to “chrome://flags” in the agent Chrome browser, search the above flag and ensure it is disabled (default=enabled).

  3. Network LatencyOne of the Finesse requirements is the that the Network Latency cannot be higher than 400ms.
    And that was exactly the problem I found on my network!!!

    But how do we find out that the latency is going over 400ms??

    Here are the instructions to gather the clientlogs from the agent Desktop side,

      *   Clear browser cache
      *   Load the following URL: <protocol>://<ip/host>:<port>/desktop/locallog and select “Sign In With Persistent Logging“.  You will be redirected to login page with the appropriate query parameter url.
      *   Sign into Finesse
      *   Operate Finesse as usual
      *   When you run into the problem open a new window or a tab and reopen with same browser type using the following URL: <protocol>://<ip/host>:<port>/desktop/locallog and select Refresh button
      *   Now you have all the logs in the contents of the console output.

  4. Conclusion


    After analysing the logs, I could find the following:

    Line 384: 2021-03-29T09:28:50.812 +02:00: 39DED1: <a href="http://<http://<<uccx_server>&gt;: Mar 29 2021 09:28:50.728 +0200: Header : Client: 2021-03-29T07:28:50.518Z, Server: 2021-03-29T07:28:50.434Z, Drift: -84ms, Network Latency (round trip): 587ms

    image

    In this Log’s pieces, we can see that the roundtrip latency for the agent that was logged out, spikes above the 400ms threshold allowed by Finesse. This latency means that the server does not receive the “Presence available” notifications from the agent PC.  After 60 seconds without receiving a notification, the system will log the agent out per design.              

  5. So now you have to troubleshoot your network to find the source of that Latency.

    That’s it guys!

    I hope this post can help you out!

    See ya!

    Bruno

    PowerShell Execution Policies

    So you decide to use PowerShell for the first time, and when you run a PowerShell script, you get a security warning or maybe you see some error messages and then the PowerShell window disappears. Here are some simple tips for your first PowerShell experience to be a success.

    Make sure you are using the latest version of PowerShell:

    https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-windows?view=powershell-7.1

    About Execution Policies

    https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.1

    Open your PowerShell console

    Always open it in elevated mode (If possible), with the title “Administrator: Windows PowerShell”. Then you try to execute a command, script or even import a module as in my example below.

    image

    This issue occurs because PowerShell starts with the execution of scripts disabled, obviously this happens for security reasons, after all, your environment can be seriously affected by a malicious script.

    In the screen below, you can see that I ran the Get-ExecutionPolicy command and the response was Restricted

    image

    There are 5 scopes of Execution Policy, and it depends on your need, but it is important that you know how to manipulate each scope and why.

    1. MachinePolicy: Set by a Group Policy for all users of the computer.
    2. UserPolicy: Set by a Group Policy for the current user of the computer.
    3. Process: The Process scope only affects the current PowerShell session. The execution policy is saved in the environment variable $env:PSExecutionPolicyPreference, rather than the registry. When the PowerShell session is closed, the variable and value are deleted.
    4. CurrentUser: The execution policy affects only the current user. It’s stored in the HKEY_CURRENT_USER registry subkey.
    5. LocalMachine: The execution policy affects all users on the current computer. It’s stored in the HKEY_LOCAL_MACHINE registry subkey.

    It is also important to know how to manipulate policies and which is the most suitable for your needs. I will list the policies that you can configure to use in your environment

    • AllSigned
    • Scripts can run.
    • Requires that all scripts and configuration files be signed by a trusted publisher, including scripts that you write on the local computer.
    • Prompts you before running scripts from publishers that you haven’t yet classified as trusted or untrusted.
    • Risks running signed, but malicious, scripts.
    • Bypass
    • Nothing is blocked and there are no warnings or prompts.
    • This execution policy is designed for configurations in which a PowerShell script is built in to a larger application or for configurations in which PowerShell is the foundation for a program that has its own security model.
    • Default
    • Sets the default execution policy.
    • Restricted for Windows clients.
    • RemoteSigned for Windows servers.
    • RemoteSigned
    • The default execution policy for Windows server computers.
    • Scripts can run.
    • Requires a digital signature from a trusted publisher on scripts and configuration files that are downloaded from the internet which includes email and instant messaging programs.
    • Doesn’t require digital signatures on scripts that are written on the local computer and not downloaded from the internet.
    • Runs scripts that are downloaded from the internet and not signed, if the scripts are unblocked, such as by using the Unblock-File cmdlet.
    • Risks running unsigned scripts from sources other than the internet and signed scripts that could be malicious.
    • Restricted
    • The default execution policy for Windows client computers.
    • Permits individual commands, but does not allow scripts.
    • Prevents running of all script files, including formatting and configuration files (.ps1xml), module script files (.psm1), and PowerShell profiles (.ps1).
    • Undefined
    • There is no execution policy set in the current scope.
    • If the execution policy in all scopes is Undefined, the effective execution policy is Restricted for Windows clients and RemoteSigned for Windows Server.
    • Unrestricted
    • The default execution policy for non-Windows computers and cannot be changed.
    • Unsigned scripts can run. There is a risk of running malicious scripts.
    • Warns the user before running scripts and configuration files that are not from the Local intranet zone.

    And finally, right after changing the execution policy in my example below to Unrestricted, it was possible to import the Azure module into the PowerShell.

    image

    Example 1: Set-ExecutionPolicy Unrestricted -force

    Example 2: Set-ExecutionPolicy RemoteSigned -force

    Note: The Parameter –Force is used only to prevent warnings from appearing, and then it is not necessary to make confirmations.

    I do not recommend leaving the policy set to Unrestricted, this was just for example. You must adapt to your need and if it is necessary to apply the Unrestricted policy do not forget to change when you finish your task. At the beginning of the article, I also left a link to Microsoft Docs where you can learn more about the subject, I will stop here and see you later!