Cross Service Query – Azure Monitor and Azure Data Explorer

Cross Service Query – Azure Monitor and Azure Data Explorer

This article is contributed. See the original author and article here.

Azure Monitor<->Azure Data Explorer cross-service querying


This experience enables you to query Azure Data Explorer in Azure Log Analytics/Application Insights tools (See more info here),


and the ability to query Log Analytics/Application Insights from Azure Data Explorer tools to make cross resource queries. (See more info here.),


adx-proxy-workflow.png


 


For example (querying Azure Data Explorer from Log Analytics):


2020-11-24_10-24-28.png


 



Where the outer query is querying a table in the workspace, and then joining with another table in an Azure Data Explorer cluster (in this case, clustername=help, databasename=samples) by using a new “adx()” function, like how you can do the same to query another workspace from inside query text.


 


Both experiences are in Private Preview.


The ability to query Azure Monitor from Azure Data Explorer is open for everyone to use – no need to be allowlisted,


The ability to query Azure Data Explorer from Log Analytics/Application Insights requires to be allowlistedWe need the following to get you enrolled (you can send the info to me):



  1. Tenant ID

  2. List of the Azure Data Explorer clusters (the list is required to enable the team to modify the callout policy of that cluster, that will allow them to communicate with the proxy)

  3. Email address


 


We started a private preview program, and we are happy to add early adopters to experience the new functionality.


Please note that the product is new with limited SLA, and we estimate that we will be able to move to pubic preview with production level SLA within ~2-4 months.

Cross Service Query – Azure Monitor and Azure Data Explorer

Cross Service Query – Azure Monitor (LA/AI) and Azure Data Explorer (ADX)

This article is contributed. See the original author and article here.

Azure Monitor<->Azure Data Explorer cross-service querying (join between LA/AI and ADX!)


 


This experience enables you to query Azure Data Explorer in Azure Log Analytics/Application Insights tools (See more info here),


and the ability to query Log Analytics/Application Insights from Azure Data Explorer tools to make cross resource queries. (See more info here.),


adx-proxy-workflow.png


 


For example (querying Azure Data Explorer from Log Analytics):


2020-11-24_10-24-28.png


 



Where the outer query is querying a table in the workspace, and then joining with another table in an Azure Data Explorer cluster (in this case, clustername=help, databasename=samples) by using a new “adx()” function, like how you can do the same to query another workspace from inside query text.


 


Both experiences are in Private Preview.


The ability to query Azure Monitor from Azure Data Explorer is open for everyone to use – no need to be allowlisted,


The ability to query Azure Data Explorer from Log Analytics/Application Insights requires to be allowlistedWe need the following to get you enrolled (you can send the info to me):



  1. Tenant ID

  2. List of the Azure Data Explorer clusters (the list is required to enable the team to modify the callout policy of that cluster, that will allow them to communicate with the proxy)

  3. Email address


 


We started a private preview program, and we are happy to add early adopters to experience the new functionality.


Please note that the product is new with limited SLA, and we estimate that we will be able to move to pubic preview with production level SLA within ~2-4 months.

How to design secure and convenient access to AKS clusters

How to design secure and convenient access to AKS clusters

This article is contributed. See the original author and article here.

API Server is a crucial component of Kubernetes that allows cluster configuration, workload management and a lot more. While this endpoint is incredibly important to secure; developers and engineers typically require regular and convenient access to that API. Striking a balance between security and convenience is quite desirable here.


 


Azure Kubernetes Service (AKS) provides two robust mechanisms to restrict access to the API Server: namely through restricting authorized source IP addresses or disabling public access to the API endpoint.
 


While the above two controls ensure additional security for the API endpoint, developers and engineers do face a few challenges here:
 



  1. With the rise of remote work, many users could be unable to keep a static source IP address that has been whitelisted by AKS.
     

  2. Although VPN solutions are increasingly deployed, many users could find that always on VPN becomes a challenge sometimes; especially if it affects an already low internet bandwidth at home.
     

  3. While some users get access to a jump box or an Azure Bastion host, it lacks many notable features like AD authentication or a true desktop experience.


Recommendations


One good approach to overcome the above challenges is to allow remote access to a fixed cloud endpoint, which has sole access to the AKS Cluster. Being more specific, Visual Studio Code Remote Development and Windows Virtual Desktop are two solutions that can provide a secure yet convenient access to restricted AKS cluster.


 


blog-secure-development.png


 


Visual Studio Code Remote Development (SSH)


VS Code Remote Development (SSH) can allow developers and engineers access from within Visual Studio Code to hardened and right-sized per-user virtual machines. The solution has the following benefits:
 



  • The virtual machines could use automation to start up and shutdown during regular work hours.

  • Users leverage their local VS Code to run code and terminal commands that are in fact running on a remote machine that has access to a restricted AKS cluster.

  • Linux users would leverage SSH keys to get access to those machines but could also evaluate the preview feature of Linux AD authentication.

  • Remote VM can be in a VNET with access to a private AKS cluster or can have an outbound IP whitelisted by AKS.


 


Windows Virtual Desktop


While the above solution has some great benefits, it requires SSH access from at least a wide array of IP ranges owned by developers or engineers. It might also require additional GUI access to the Azure virtual machines to run some Kubernetes tools such as Lens, a Kubernetes IDE. Windows Virtual Desktop on the contrary requires no open SSH ports and provides desktop access. It just requires TCP port 443 access to a defined Microsoft endpoint. Other benefits from this solution include:
 



  • Use various clients such as Windows, macOS, Android, iOS, or Web.

  • Desktop discovery based on AD Authentication. No IP or host name distribution required.

  • Full desktop experience with Windows 10 or Windows 7.

  • Users might be able to leverage existing licenses to assign desktops.

  • Desktop host can be in a VNET with access to a private AKS cluster or can use a Load Balancer outbound IP whitelisted by AKS.


 


Whichever solution you choose to provide access to an AKS cluster, it’s quite important to try strike a balance between meeting security requirements and ensuring teams productivity. VS Code Remote Development and Windows Virtual Desktop are two options worth considering.

Remember it all with Microsoft To Do and Samsung Reminder

Remember it all with Microsoft To Do and Samsung Reminder

This article is contributed. See the original author and article here.

We have a super exciting announcement to make. You can now sync your reminders on Samsung Reminder app with To Do. It’s a great way to access your phone reminders created from Bixby, calls, notes, messages, etc. on PC and browser apps of To Do, Outlook and Teams. 


 



 


3 ways to get the best out of it 



  • Now, more than ever, it’s important to connect. Create a reminder from a call and it will be available with all your tasks in To Do. Even better, you can click on ‘Open in Dialer’ to start your call right from your laptop with Your Phone app.

  • Use Bixby to quickly capture a reminder on the go. Just say “Bixby, remind me to pay bills this evening” and the captured reminder would sync and be available on your PC and web. 

  • Create a reminder from Samsung Messages, Samsung Notes, or Samsung browser, then manage them in the To Do app on your PC. 


Manage reminders from Samsung Galaxy in To DoManage reminders from Samsung Galaxy in To Do


 


How to start syncing?


To start syncing your To Do lists and tasks with Samsung Reminder, connect it to Microsoft To Do: 



  1. Open the Samsung Reminder app > Settings > Sync with Microsoft To Do.  

  2. Sign in with your Microsoft account. 

  3. Accept the permission request and you’re good to go! 


Steps to start syncing with Samsung Reminder appSteps to start syncing with Samsung Reminder app


 


It’s important that you set To Do as your default list so that reminders created from outside of the Reminder app e.g. from Bixby, calls, etc., are synced with To Do. To do that, open your Samsung Reminder app settings > Save Reminders from other apps to Microsoft To Do. 


Steps to set To Do as defaultSteps to set To Do as default


 


Note: Samsung Reminder sync with Microsoft To Do is available for all Galaxy Models with Android 10 or higher.


 


We can’t wait to hear what you think of this integration – let us know in the comments below or over on Twitter and Facebook. You can also write to us at todofeedback@microsoft.com. 


 


 


 

Upgrade your MySQL v5.6 servers with ease and make your end of support planning a bit easier !!!

Upgrade your MySQL v5.6 servers with ease and make your end of support planning a bit easier !!!

This article is contributed. See the original author and article here.

Major version upgrades of production databases can be stressful and a significantly time-consuming and costly project if you are dealing with a fleet of database servers to upgrade. You are expected to deal with a daunting list of tasks to plan and execute a seamless upgrade with minimal impact to the business. The tasks are daunting not because they are complex but because the stakes are high. You will need to practice and practice until you get perfection and confidence to execute upgrade of your production environment flawlessly in the acceptable downtime window. Some of these tasks can be automated but generally each environment is a bit different (for e.g. Ubuntu 16 vs Ubuntu 18) and often heavily customized for the application or business it is running. This makes automation of the task a bit challenging. The practice session may involve building production like environment, testing the application for compatibility, simulating the workload, practicing the steps multiple times, and documenting it to ensure all the dependencies or customizations are taken care of. This makes the upgrade process stressful as it involves multiple manual steps and error prone when you are working under pressure towards a tight deadline. We are trying to make this process a bit easy for you with our new major version upgrade feature in Azure Database for MySQL service.


 


With the release of Major Version Upgrades in Azure Database for MySQL, you can now upgrade your MySQL v5.6 servers to MySQL v5.7 with a click of a button.


 


In Azure portal, on the Overview blade, you will now see an Upgrade button for MySQL v5.6 servers that can use to upgrade your existing MySQL servers.


 


upgrade.png


 


You can learn more about how to upgrade using this feature in our documentation.


While this feature doesn’t promise to take all your problems away :smiling_face_with_smiling_eyes: (I wish we had that magic wand) but together with managed service value proposition, it does promise to simplify some of the tasks for you. For instance –


 



  • Simulating a production like environment – This is easy with managed service as you can use point in time restore feature (another turnkey solution) to clone your production environment.

  • Practicing upgrades – With multiple manual steps taken out from your upgrade document and replaced with a single step of a click of a button, this becomes a simplified experience which can be further be automated using Azure CLI.

  • Managing upgrades for a fleet of servers – You can use Azure CLI to automate restore and upgrade operations which can then be used to run across the fleet of servers with ease.

  • No dealing of customized environments – With standardization and restricted access to a managed service, you do not need to worry about customized environment which is often the common causes of failed upgrades as there is heavy customization at the underlying OS and filesystem.


While the above challenges are addressed and simplified with this feature, you can focus your energy on


 



  • Understanding the changes in MySQL 5.7 to drive clarity to your business and development team on what will break or behave differently in MySQL 5.7.

  • Test your application compatibility to ensure it works as intended and the compatibilities are addressed.

  • Estimate and plan for the downtime required for the upgrades and execute the upgrade operation during your planned maintenance window.


Sometimes testing the application compatibility and upgrading the application code is the most challenging task of the upgrade and time/effort consuming too so can we afford to not be under the gun for upgrade timelines.  The answer to that is: Yes.


 


We have updated our retirement policies for Azure Database for MySQL where we have clearly documented the restrictions if you chose to run your servers after retirement date and what you can expect.


 


It is now time for you to plan your upgrades of MySQL v5.6 servers as the end of support is approaching soon on February 5, 2021.


 


Let us know how we can help. Please reach out to us (Mailto: AskAzureDBforMySQL@service.microsoft.com) if you have questions or need clarification.