This article is contributed. See the original author and article here.
The security community is continuously changing, growing, and learning from each other to better position the world against cyberthreats. In the latest post of our Community Voices blog series, Microsoft Senior Product Marketing Manager Brooke Lynn Weenig talks with Trimarc Founder and Chief Technology Officer Sean Metcalf, who is a Microsoft Certified Master in Active Directory,co-hosts the Enterprise Security Weekly podcast, and created the adsecurity.org website.The thoughts below reflect Sean’s views, not the views of Sean’s employer, and are not legal advice. In this blog post, Sean talks about securing identities.
Brooke: How did you get into Active Directory security?
Sean: When Active Directory came out, I was excited because Microsoft was my technology focus and this was an intriguing new direction. The environment where I worked had Novell NetWare everywhere, and one group was running Windows NT exclusively. I ran Windows NT within this little island and figured out how to navigate the idiosyncrasies that were NT. Once Active Directory was released, I switched to a consulting job to help customers deploy Active Directory.
Active Directory launched with quite a bit of features we did not have with NT, like group policies and other items that help manage the environment. This was a huge improvement over the older NT domain environment. The security side of AD was a bit less clear.
In the early 2000s, I worked as a consultant on a large global multidomain Active Directory deployment. The size of the environment and the global distribution, not to mention active migration efforts, added complexity which resulted in security concerns. To help secure this AD environment, I shifted my focus to Active Directory security. I started trying to figure out what was missing as this environment was getting deployed, configured, and rolled out all around the world, not to mention the approximately 1,000 domain controllers arrayed around the globe. My approach focused on the attacker mindset:
How could I compromise this environment or do something that it is not meant to do? What did we not think about when we were designing it that we should have? And the question many ask themselves about their own AD environment: what am I missing…?
Soon after this, I started the ADSecurity.org website, initially as my “web notebook” that I referred customers to; this became a central location for noting Active Directory security concerns and issues that I saw.
Brooke: What are the biggest challenges of securing identity?
Sean: Active Directory is not inherently insecure. One challenge is that it is a system much like any other, with a variety of configurable options. Since AD offers such great customization, people can do whatever they want, and AD environments can look very different. Admins can add regular user accounts into domain admins (and they have!). They can add certain groups that contain everyone in Active Directory into highly privileged AD groups and give everyone rights. Active Directory is not going to stop you from doing that any more than your car is going to stop you from driving too fast on a residential street.
Another challenge is that there are often too many privileged accounts that have rights that are not really required. The organization does not know all the accounts with highly privileged rights. Group nesting is still an issue in Active Directory that leads to insecure configuration. This is where you have a group that is a member of one group that is a member of another group. Due to this group nesting configuration, the Administrators group at the domain level granted full AD administrative rights to every member of all these groups (and member accounts) in the chain.
Service accounts are associated with an application but are often highly privileged in AD. The challenge is identifying the accounts that have rights because Active Directory security does not always come down to just membership of domain admins and administrators, but delegated rights through AD permissions and group policy rights assignments.
Another challenge is with Active Directory permissions set years ago and forgotten. All these groups and accounts have rights, but nobody knows about them (or remembers!).
That is what the focus for Active Directory security often is – Active Directory integrations, Azure AD Connect, and enterprise password vault features, like secret server and CyberArk – these systems that are highly privileged in Active Directory, but not often reviewed.
Finally, hundreds of companies help move companies into the cloud, but not as many helps them secure it. Azure AD has the same issue of too many privileged accounts, but often with regular user accounts in these privileged Azure AD roles. Group nesting is now something you can do within Azure AD, so that adds another level to it where you can have role-assignable groups that can be placed into an Azure AD privilege role. You end up with another layer and having to figure out who is in that group. With Privileged Identity Management in Azure AD, you can have a role assignable group or have members of that group eligible (or permanently assigned) to be global, application or user administrators. Once you have that layer of abstraction, it gets more difficult to determine what a group does and who should be put into it.
In the world of identity, the challenge comes down to knowing which account has privileged access and protecting those accounts from attack.
Brooke: What vulnerabilities and response times do you see on Azure Active Directory?
Sean: Many issues I hear from incident response partners are with Azure AD configurations. A lot of the defaults are too permissive. Users and guests have too many capabilities. We are starting to see them tighten up, like Azure AD “security defaults” that turn off legacy authentication by default.
Attackers sometimes phish a user and the user sees what looks like a legit application requesting permissions, but it is an application that the attacker created. The attacker then has full access. The attacker could pull data through the application continuously and the user does not even know about it. This is not just a Microsoft thing. This happens due to OAuth and other cloud providers such as Google are susceptible.
In other attacks, the attacker keeps calling the admin until they consent to the multifactor authentication prompt. This is why Microsoft has pushed for number-matching, because number-matching requires that you think about, “What is the number on the screen and the thing that I am authenticating to” and you have to enter that number into the app to complete that multifactor authentication response. This validates that the person requesting the access is the person confirming the access versus just accepting a push response of “Accept” or “Deny”.
In Azure AD, regular users may get full rights to add a credential to an application to a level way above what their rights actually are based on their role membership. There are applications in many tenants around the world that have effective global admin rights and if there is a regular user who created that application and got it approved through the normal process, they are an owner. A compromise of that regular user account could completely compromise the tenant.
Attackers are going after permissions and anything to get a foothold. During the SolarWinds incident, many saw compromise of the on-prem environment and accounts and then the attacker leveraged these credentials to pivot into the cloud. That is a challenge for a lot of organizations because the cloud is seen as an extension of the on-prem environment, where we often see synchronized accounts in Active Directory that are members of highly privileged roles in Azure AD, like Global Administrator.
If neither Conditional Access nor security defaults are enabled, that is a problem. Conditional Access is effectively an identity firewall for the Microsoft cloud environment where you can control who can connect to what, how, and where. All those answers can be done within Conditional Access and Microsoft continues to expand this capability. An Azure AD risk is not enforcing multifactor authentication on all privileged accounts, not just global admin, because there are other roles that are highly privileged. There is even an Azure AD permission where the application delegated this right can give itself its own permissions to have full admin rights to the Azure AD tenant.
Brooke: What challenges are you seeing in the world of permissions and roles?
Sean: One of the biggest challenges many organizations are experiencing today relates to what I call the “Identity Nexus”. The Identity Nexus is where identities across systems connect and often provides attackers opportunity.
We have all these identity systems— on-prem Active Directory, Azure AD, Okta, and other cloud providers, like Google Cloud Platform or Amazon Web Services). Each has its own Identity Access Management system, roles, and permissions. Some things are similar across cloud providers, but there is different nomenclature across cloud providers and a variety of capabilities as far as security, management, and operations. These differences, paired with the required interconnectivity between cloud and on-prem (the nexus), can result in interesting scenarios where a cloud admin can make changes that affect on-prem administration, including updating on-prem privileged access!
Often, Active Directory is still the core of identity. Most companies have on-prem Active Directory accounts that are synchronized with Azure AD, which means there are Azure AD accounts linked to the AD accounts. Unprivileged accounts in Active Directory can have highly privileged rights through Azure AD roles and depending on the configuration, there may be unintended consequences related to our identity systems and infrastructure systems of which attackers can take advantage.
Another interesting connection point between on-prem and cloud is when there is a domain controller virtualized in Azure that is part of the on-prem Active Directory. This configuration could result in the compromise of the on-prem Active Directory due to a breach in the cloud environment.
There are unintended consequences with how most organizations are connecting things across the Identity Nexus, especially with hybrid cloud components like Azure AD Connect. There is interplay among hybrid cloud components and Azure AD Connect is often at the center of this. Common hybrid components include Azure AD, Seamless Single Sign-On, and Pass-Through Authentication. With Pass-Through Authentication, credentials pass through that system that enables an attacker to potentially spoof and impersonate someone on the network if the server is not protected appropriately. This underscores the importance of protecting both the hybrid systems and privileged credentials.
Strong authentication, like Multifactor Authentication, secured systems like Privileged Access Workstations for highly privileged accounts, and limiting rights that service accounts and third-party systems have are the most important ways to protect identity.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and Twitter (@MSFTSecurity) for the latest news and updates on cybersecurity.
This article is contributed. See the original author and article here.
In today’s fast-paced digital world, databases are at the heart of almost every application or service. Databases are responsible for storing and managing vast amounts of data, providing real-time access to information, and powering critical business operations. As the amount of data and the number of users accessing databases continues to grow, it is essential to ensure that they can handle the expected workload and perform efficiently under heavy traffic. Whether you are launching a new application or getting ready for peak traffic, load testing helps you ensure that your database can handle the load and deliver reliable performance.
While most database queries typically happen through an application endpoint, there are situations where it is beneficial to directly test the database without involving intermediaries. One such scenario is when you want to assess the performance of a specific query without executing every query in the system or to evaluate the performance of a new query under heavy load. It could also be that your database is used by multiple applications.
In this blog post we will look at load testing Azure SQL Database using Azure Load Testing. You can use a similar approach to test other databases on Azure like MongoDB, PostgreSQL etc. We will cover everything you need to know, from setting up your JMeter script, to running the load test and identifying performance bottlenecks.
Setting up Azure SQL Database
The first step in load testing an Azure SQL Database is setting it up. You can use an existing Azure SQL Database instance. For this blog post, we’ll use a sample database. You can create your own sample instance using the Azure portal.
Once you have created the instance, note down the server name, database name, and login credentials. You will need these details later to connect JMeter to the database. Make sure to allow Azure services and resources to access your Azure SQL server as shown below.
Screenshot of Networking tab in Azure SQL Database
Setting up the JMeter script
To load test your Azure SQL DB you will need to download the Microsoft JDBC Driver for SQL Server . You can download the driver here. Follow the steps below to. You use the artifacts from the samples repository to set up the load test.
Open JMeter and create a new test plan. In your JMeter Test Plan browse and choose the JDBC driver. Screenshot of JDBC driver configuration in JMeter GUI
Add a JDBC Connection Configuration element to the test plan.
The server name, database name , and login credentials for the Azure SQL Database instance are parameterized and can be provided using environment variables and secrets. You can store the password in an Azure Key Vault and access the same in your JMeter script using the GetSecret function. See the using secrets in Azure Load Testing docs for more detail.
Screenshot of database configuration in JMeter GUIScreenshot of user defined variables in JMeter GUI
Add a Thread Group element to the test plan.
Configure the Thread Group element to simulate the desired number of users and requests. In this script we have parameterized the concurrent threads (users) and duration as environment variables.
Add a JDBC Request element to the Thread Group.
Enter the SQL query that you want to execute on the Azure SQL Database instance. You can add multiple requests for multiple queries.
If your queries require input data, you can add a CSV input file to provide data to the JMeter script.
Running the load test
You can now run this script on Azure Load Testing.
Create a test by selecting Upload a JMeter script.
Upload the JMeter script, the JDBC driver and the CSV file. You need to upload this because it is not already installed on the test engine. Screenshot of test creation in Azure Load Testing
In the parameters tab, add the following.
The environment variable values for the following
threads – the number of concurrent users per engine
duration – the duration of the test.
Database – the database URL
Username – the username to login to the database
The password as a secret. Enter the secret name and the secret identifier from the Azure Key Vault (AKV). Remember to grant ‘Get’ permission on secrets to this load testing resource on the AKV using managed identity. Screenshot of parameters in Azure Load Testing
In the Monitoring tab, select your Azure SQL database instance. By default you can view the CPU percentage, connections failed and deadlocks for your SQL database.
Select Review + Create to create and run the test.
Monitoring
Once the test run starts, you can monitor the client side and server side metrics on the dashboard in real time. The load begins to ramp up slowly to 150 virtual users and after the load reached the maximum virtual users, the database started returning errors. The errors are of type ‘request limit has exceeded’.
Screenshot of test results in Azure Load Testing with errors
You can monitor the server side metrics as well to understand the reason for errors. You can click on Configure metrics to add additional metrics to monitor the performance of your database. As you can see, the average CPU percentage and average DTU percentage peaked after some time. Azure SQL Database recommends setting alerts for if the average CPU and DTU percentage go above 80%.
Screenshot of test results in Azure Load Testing with high CPU and DTU percent
Fixing performance bottlenecks
Once you have identified performance issues, you can take steps to optimize the performance of your Azure SQL Database. Some tips to improve the performance of your Azure SQL Database include:
Index optimization: Ensure that your database has the appropriate indexes to speed up query execution.
Query optimization: Optimize your SQL queries to ensure that they are as efficient as possible.
Scaling: Consider scaling up or out to increase the capacity of your Azure SQL Database.
In this case I know that my database is not able to handle the load because of the limit in DTUs. Now scale up the Azure SQL Database to 200 DTUs. Once done, re-run the test in Azure Load Testing and monitor the metrics.
Screenshot of test results in Azure Load Testing with no errors
Now I see that there were no errors and the average CPU and DTU percentages were within acceptable limits.
Screenshot of test results in Azure Load Testing with low CPU and DTU percent
Conclusion
In conclusion, load testing is an essential aspect of database performance testing. It helps to identify performance bottlenecks, improve database performance, and ensure that it can handle the expected workload. Remember, load testing should be an ongoing process, so make sure to integrate load tests in your CICD workflows to identify any issues early in the development lifecycle and optimize your database’s performance.
If you have any feedback on Azure Load Testing, let us know through our feedback forum. Refer to the previous blogs on Azure load testing here. The resources used in this blog post are available in the Azure Load Testing samples repository.
This article is contributed. See the original author and article here.
A common scenario for Field Service organizations is to augment their staff with external vendor resources. Leveraging Azure Active Directory B2B Guest Access, vendors can be added to the organizational directory without being created as full first party users within the organization. This allows a clean delineation of users to manage security and data access.
Dynamics 365 has made this vendor onboarding process even easier with Wave 1 2023 by introducing Tenant Switcher for Field Service Mobile. Tenant Switcher provides a user interface where guest users can now easily switch between their Home and Guest Tenants.
Other considerations to note:
Guest Users require a Field Service license and appropriate Security role for access to Field Service Mobile.
Model Driven Application Authentication supports work or school accounts. AAD B2B Guest users configured with a personal account would not be able to authenticate and access the Field Service Mobile application directly.
This article is contributed. See the original author and article here.
The Breakthru app in Teams is available to more than 300 million potential monthly active users in 500,000 organizations. Finding the right audience is critical for independent software vendors (ISVs), and just three years after launching on Teams, Breakthru reaches more than 45,000 organizations worldwide, with a growing customer base.
This article is contributed. See the original author and article here.
This week I had a service request where our customer didn’t have a connection retry logic implemented in their application code in the event of a connection failure to Azure SQL. I would like to share an example about how to implement it.
First the C# code using ODBC API:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Runtime.InteropServices;
using System.Diagnostics;
namespace DotNetExample
{
class ClsODBCAPI
{
// Import the ODBC API functions using P/Invoke
[DllImport("odbc32.dll")]
private static extern short SQLAllocHandle(short handleType, IntPtr inputHandle, out IntPtr outputHandle);
[DllImport("odbc32.dll")]
private static extern short SQLSetEnvAttr(IntPtr environmentHandle, int attribute, IntPtr valuePtr, int stringLength);
[DllImport("odbc32.dll")]
private static extern short SQLConnect(IntPtr connectionHandle, string serverName, short nameLength1, string userName, short nameLength2, string password, short nameLength3);
[DllImport("odbc32.dll")]
private static extern short SQLExecDirect(IntPtr statementHandle, string query, int textLength);
[DllImport("odbc32.dll")]
private static extern short SQLFetch(IntPtr statementHandle);
[DllImport("odbc32.dll")]
private static extern short SQLGetData(IntPtr statementHandle, short columnIndex, short targetType, IntPtr targetValue, int bufferLength, out int indicatorValue);
[DllImport("odbc32.dll")]
private static extern short SQLDisconnect(IntPtr connectionHandle);
[DllImport("odbc32.dll")]
private static extern short SQLFreeHandle(short handleType, IntPtr handle);
[DllImport("odbc32.dll")]
private static extern short SQLGetDiagRec(
short handleType,
IntPtr handle,
short recordNumber,
IntPtr sqlState,
out int nativeError,
IntPtr messageText,
short bufferLength,
out short textLength
);
public void Main()
{
// Initialize ODBC environment handle
IntPtr environmentHandle = IntPtr.Zero;
SQLAllocHandle(1, IntPtr.Zero, out environmentHandle);
SQLSetEnvAttr(environmentHandle, 200, (IntPtr)3, 0);
// Initialize ODBC connection and statement handles
IntPtr connectionHandle = IntPtr.Zero;
IntPtr statementHandle = IntPtr.Zero;
short retcode;
retcode = SQLAllocHandle(2, environmentHandle, out connectionHandle);
try
{
// Connect to the database
retcode = RetryLogicUsingODBCAPI(connectionHandle);
if( retcode != 1 )
{
return;
}
retcode = SQLAllocHandle(3, connectionHandle, out statementHandle);
// Prepare and execute a query
SQLExecDirect(statementHandle, "SELECT top 200 TextToSearch FROM PerformanceVarcharNVarchar", 60);
// Fetch and display the result set
int id = 0;
while (SQLFetch(statementHandle) == 0)
{
// Retrieve data for each column
id = id + 1;
int nameLength = 200;
IntPtr namePtr = Marshal.AllocHGlobal(nameLength);
SQLGetData(statementHandle, 1, 1, namePtr, nameLength, out nameLength);
string name = Marshal.PtrToStringAnsi(namePtr);
Console.WriteLine("ID: " + id);
Console.WriteLine("Name: " + name);
Marshal.FreeHGlobal(namePtr);
}
}
catch (Exception ex)
{
// Handle any errors that occur
Console.WriteLine("Error: " + ex.Message);
}
finally
{
// Disconnect and free resources
SQLDisconnect(connectionHandle);
SQLFreeHandle(3, statementHandle);
SQLFreeHandle(2, connectionHandle);
SQLFreeHandle(1, environmentHandle);
}
}
private short RetryLogicUsingODBCAPI(IntPtr connectionHandle)
{
int maxRetryAttempts = 5;
int retryIntervalSeconds = 10;
int retryCount = 0;
short retcode = 0;
TimeSpan ts;
string elapsedTime;
Stopwatch oConnTime = new Stopwatch();
while (retryCount < maxRetryAttempts)
{
try
{
retryCount++;
retcode = SQLConnect(connectionHandle, "DSNName", 7, "username", 8, "Password", 8);
if (retcode == 1)
{
ts = oConnTime.Elapsed;
elapsedTime = String.Format("{0:00}:{1:00}:{2:00}.{3:00}", ts.Hours, ts.Minutes, ts.Seconds, ts.Milliseconds / 10);
Console.WriteLine("Connected to the database. Time Spent:" + elapsedTime);
return retcode;
}
else
{
Console.WriteLine("SQLConnect failed with retcode: " + retcode);
GetODBCErrorDetails(connectionHandle);
Console.WriteLine("Retrying connection...in...{0} ms", (1000 * retryIntervalSeconds));
System.Threading.Thread.Sleep(1000 * retryIntervalSeconds);
retryIntervalSeconds = Convert.ToInt32(retryIntervalSeconds * 1.5);
}
}
catch (Exception ex)
{
Console.WriteLine("Error: " + ex.Message);
}
}
return -1;
}
static void GetODBCErrorDetails(IntPtr handle)
{
const int SQL_HANDLE_ENV = 1;
const int SQL_HANDLE_DBC = 2;
IntPtr sqlStatePtr = Marshal.AllocHGlobal(6);
IntPtr messageTextPtr = Marshal.AllocHGlobal(1024);
int nativeError;
short textLength;
short retcode = SQLGetDiagRec(
SQL_HANDLE_DBC,
handle,
1,
sqlStatePtr,
out nativeError,
messageTextPtr,
1024,
out textLength
);
if (retcode == 0)
{
string sqlState = Marshal.PtrToStringAnsi(sqlStatePtr);
string messageText = Marshal.PtrToStringAnsi(messageTextPtr, textLength);
Console.WriteLine("ODBC Error Details:");
Console.WriteLine("SQLState: " + sqlState);
Console.WriteLine("Native Error: " + nativeError);
Console.WriteLine("Message: " + messageText);
}
else
{
Console.WriteLine("Failed to retrieve ODBC error details.");
}
Marshal.FreeHGlobal(sqlStatePtr);
Marshal.FreeHGlobal(messageTextPtr);
}
}
}
This first of the code declares and imports the required functions from the odbc32.dll library using P/Invoke. These functions are used to interact with the ODBC API.
In the Main method, the ODBC environment handle is initialized using SQLAllocHandle function. The SQLSetEnvAttr function is used to set the environment attribute. Then, the ODBC connection and statement handles are initialized using SQLAllocHandle.
Inside the try block, the RetryLogicUsingODBCAPI method is called to establish a connection to the database. If the connection is successful (retcode = 1), a query is executed using SQLExecDirect. The result set is fetched using SQLFetch, and the data is displayed.
In case of any errors, the catch block handles and displays the exception message. The finally block is used to disconnect from the database and free the allocated resources.
The RetryLogicUsingODBCAPI method is responsible for implementing the connection retry logic. It attempts to connect to the database using SQLConnect within a while loop. If the connection is successful (retcode = 1), it returns the retcode. Otherwise, it displays the failure details, waits for a specified interval, and increases the interval for subsequent retries.
The GetODBCErrorDetails method retrieves ODBC error details using SQLGetDiagRec function. It takes the handle as input and retrieves the SQLState, native error code, and message text associated with the error.
This article is contributed. See the original author and article here.
Hi!
Ready to meet your new best friend? Say hello to GitHub Copilot, the AI pair programmer that’s about to change the way you code. It’s like having a super-smart friend who’s always ready to help. No matter the scenario, writing code, fixing bugs, or just trying to remember that one command you always forget.
We’ve got a brand-new GitHub Copilot Fundamentals Learning Path all about GitHub Copilot. What’s a Learning Path, you may ask? Well, it’s a sequence of courses that guides you step-by-step to learn new skills and discover the power of Microsoft products. You can find all sorts of Learning Paths on Microsoft Learn.
Our new Learning Path is split into two parts: “Introduction to GitHub Copilot” and “Introduction to GitHub Copilot for Business“.
In the first part, you’ll get to know GitHub Copilot and all its cool features. It’s like having a ChatGPT friend right in your editor, helping you out with code, error messages, and even generating unit tests. Plus, it’s got your back when you’re working on pull requests or need help with documentation. And let’s not forget about the command line – GitHub Copilot CLI is like the ultimate cheat sheet!
The second part is all about GitHub Copilot for Business. (Spoiler: this is where things get serious). We’re going to review business scenarios like: AI-based security vulnerability filtering, VPN proxy support, and a super simple sign-up process. Imagine having a complete squad of Coding experts ready to help your business code faster and smarter.
This article is contributed. See the original author and article here.
‘Offline-first’ with the Dynamics 365 Field Service Mobile application offers many advantages for frontline workers. The offline-enabled application will allow frontline workers to perform functions while they are in the field, without depending on an internet connection. This keeps them productive even in environments without high quality network coverage, which can be a common problem in rural locations or even remote urban areas where network coverage is poor.
In this blog post we will share details on recent enhancements to the Dynamics 365 ‘Offline-first’ as well as some new capabilities to help your organization debug customizations with the offline application. Let’s go!
Wave 1 2023 enhancements
With the release of Wave 1 2023, frontline workers will have a faster sync experience and better visibility into the sync status of their offline-enabled Field Service Mobile application.
The offline sync icon is now moved from the sitemap to the header of the application providing an ever-present status of their offline app.
Based on states of the icon, the offline-enabled frontline worker can see if their application is connected to Dataverse, a sync is actively running, an up-sync in pending, or if the previous sync resulted in an error. This will allow the user to make informed decisions while in the field. For example, if an up-sync is pending after a period of being without network access, they will know to connect and allow that sync to complete so all their changes can be viewed by the back office.
The offline status page is also enhanced with more details on the sync, the size on disk and app connectivity status.
In addition to offline-related interface update, the sync experience is faster and more reliable. This includes optimizations to intelligently sync table or metadata changes, and improved parallelization to bring down data faster – including when the application is accessed in a way which forces a record sync such as launching the app via push notification.
Debugging the offline application
Debugging on a mobile application can be a difficult task, which is made more challenging when introducing unique aspects of ‘Offline’ mode. To help support customers who require customizations and enhancements while working offline we have introduced debugging capabilities for the model driving applications running on Android and Windows platforms, iOS platform compatibility is coming soon.
This article is contributed. See the original author and article here.
Since Azure Stack HCI 21H2, customers have used Network ATC to:
Reduce host networking deployment time, complexity, and errors
Deploy the latest Microsoft validated and supported best practices
Ensure configuration consistency across the cluster
Eliminate configuration drift
Network ATC has led to HUGE reductions in customer support cases which means increased uptime for your business applications and less headaches for you! But what if you already deployed your cluster? How do you take advantage now that you’re travelled through that trepidatious train of thought against taking on new technology?
With minimal alliteration, this article will show you how to migrate an existing cluster to Network ATC so you can take advantage of all the benefits mentioned above. Once completed, you could easily cookie-cut this configuration across all new deployments using our previous blog; so this would be a one-time migration, and all new clusters will gain the benefits!
Before you begin
Since this is a live cluster with running VMs, we’ll take some precautions to ensure we’re never working on a host with a running VM on it. If you don’t have running workloads on these nodes, you don’t need these instructions. Just add your intent command as if this was a brand-new cluster.
As some background, Network ATC stores information in the cluster database which is then replicated to other nodes in the cluster. The Network ATC service on the other nodes in the cluster see the change in the cluster database and implements the new intent. So we setup the cluster to receive a new intent, but we can also control the rollout of the new intent by stopping or disabling the Network ATC service on nodes that have virtual machines on them.
Procedure
Step 1: Install the Network ATC feature
First, let’s install Network ATC on EVERY node in the cluster using the following command. This does not require a reboot.
Install-WindowsFeature -Name NetworkATC
Step 2: Pause one node in the cluster
Pause one node in the cluster. This node will be migrated to Network ATC. We’ll repeat this step later for other nodes in the cluster too. As a result of this pause, all workloads will migrate to other nodes in the cluster leaving this machine available for changes. To do this, you can use the command:
Suspend-ClusterNode
Step 3: Stop the Network ATC service
For all nodes that are not paused, stop and disable the Network ATC service. As a reminder, this is to prevent Network ATC from implementing the intent while there are running virtual machines. To do this, you can use the commands:
Next, we’ll remove any previous configurations that might interfere with Network ATC’s ability to implement the intent. An example of this might be a Data Center Bridging (NetQos) policy for RDMA traffic. Network ATC will also deploy this, and if it sees a conflicting policy, Network ATC is wise enough not to interfere with it until you make it clear which policies you want to keep. While Network ATC will attempt to “adopt” the existing configuration if the names match (whether it be NetQos or other settings) it’s far simpler to just remove the existing configuration and let Network ATC redeploy.
Network ATC deploys a lot more than these items, but these are the items that need to be resolved before implementing the new intent.
VMSwitch
If you have more than one VMSwitch on this system, ensure you specify the switch attached to the adapters that will be used in this intent.
If you accidentally deployed an LBFO team, we’ll need to remove that as well. As you might have read, LBFO is not supported on Azure Stack HCI at all. Don’t worry, Network ATC will prevent these types of accidental oversights in the future as it will never deploy a solution that we do not support.
If the nodes were configured via VMM, these configuration objects may need to be removed from VMM as well.
Step 5: Add the Network ATC intent
It’s now time to add a Network ATC intent. You’ll only need to do this once since Network ATC intents are implemented cluster wide. However, we have taken some precautions to control the speed of the rollout. In step 2, we paused this node so there are no running workloads on it. In step 3, we stopped and disabled the Network ATC service on nodes where there are running workloads.
If you stopped and disabled the Network ATC service, you should start this service on this node only. To do this, run the following command:
Now, add your Network ATC intent(s). There are some example intents listed on our documentation here.
Step 6: Verify deployment on one node
To verify that the node has successfully deployed the intent submitted in step 5, use the Get-NetIntentStatus command as shown below.
Get-NetIntentStatus -Name
The Get-NetIntentStatus command will show the deployment status of the requested intents. Eventually, there will be one object per intent returned from each node in the cluster. As a simple example, if you had a 3-node cluster with 2 intents, you would see 6 objects returned by this command, each with their own status.
Before moving on from this step, ensure that each intent you added has an entry for the host you’re working on, and the ConfigurationStatus shows Success. If the ConfigurationStatus shows “Failed” you should look to see if the Error message indicates why it failed. We have some quick resolutions listed in our documentation here.
Step 7: Rename the VMSwitch on other nodes
Now that one node is deployed with Network ATC, we’ll get ready to move on to the next node. To do this, we’ll migrate the VMs off the next node. This requires that the nodes have the same VMSwitch name as the node deployed with Network ATC. This is a non-disruptive change and can be done on all nodes at the same time.
Why don’t we change the Network ATC VMSwitch? Two reasons, the first is that Network ATC ensures that all nodes in the cluster have the same name to ensure live migrations and symmetry. The second is that you really shouldn’t need to worry about the VMSwitch name. This is simply a configuration artifact and just one more thing you’d need to ensure is perfectly deployed. Instead of that, Network ATC implements and controls the names of configuration objects.
Step 8: Resume the cluster node
This node is now ready to re-enter the cluster. Run this command to put it back into service:
Resume-ClusterNode
Step 9: Rinse and Repeat
Each node will need to go through the procedure outlined above. To complete the migration to Network ATC across the cluster, repeat steps 1 – 4, 6 and 8.
Summary
Migrating your existing clusters to Network ATC can be a game-changer for your cluster infrastructure and management. By automating and simplifying your network management, Network ATC can help you save time, increase efficiency, improve overall performance and avoid cluster downtime.
If you have any further questions or would like to learn more about Network ATC, please don’t hesitate to reach out to us!
This article is contributed. See the original author and article here.
Customer service agents in a digital contact center interact with multiple customers daily through live chat, phone calls, and social media channels. During customer interactions, often they find themselves searching for relevant information on various screens or other systems, resulting in increased wait time for the end customer. Also, they want to quickly capture or update the information about their conversation, in real time without having to create or link a case to a conversation. Recent enhancements to the Active Conversation form allow agents to access and edit relevant information without any screen switching.
Now, agents have all the relevant information at their fingertips, so that they spend less time looking for information on different screens or systems and help customers quickly. This leads to a reduction in average wait time and better customer satisfaction.
Customize the Active Conversation form
This feature allows administrators to add custom fields on the conversation form and embed canvas apps to display the information from external sources. To ensure agents can capture information quickly, it offers agents the flexibility to view pre-filled information and update it as needed while interacting with the customer. They can view the records related to the conversation on the sub-grids.
Access the enhanced Active Conversation form
The Active Conversation form now displays the Customer 360 card. This allows agents to view information related to the customer. They can also make inline edits without having to navigate to contact or account form. Similarly, it shows case details with information related to the case linked to the conversation and allows agents to make inline edits as needed. Administrators can configure the fields they want to show on both these cards.
Additionally, the form includes the configurable recent cases card. This shows the color-coded priority and case status for easy discoverability by the agents. Moreover, switching from the active to the closed conversation form is restricted when the conversation is still active. The reverse is true as well.
Administrators can enable these enhancements in the Customer Service workspace application by navigating to the Customer Service Admin center > Workspaces > Active Conversation form settings.
Recent Comments