What is Azure Cognitive Services?

In today's digital age, where data is considered the new oil, businesses rely heavily on data-driven insights to make informed decisions. Azure Cognitive Services is one such tool that enables businesses to leverage the power of Artificial Intelligence (AI) to derive insights from the data they collect.

Azure Cognitive Services is a collection of pre-built APIs, SDKs, and services that enables developers to add intelligent features to their applications without requiring any prior knowledge of machine learning or AI. In this article, we will take a closer look at what Azure Cognitive Services is and how it can benefit businesses.

What are Azure Cognitive Services?

Azure Cognitive Services is a cloud-based toolset that provides pre-built APIs, SDKs, and services that enable developers to add intelligent features to their applications. The toolset includes a wide range of services, including computer vision, natural language processing, speech recognition, and more.

These services are powered by Microsoft's AI algorithms and can be integrated into existing applications to add intelligent features such as image recognition, language translation, sentiment analysis, and more.

How does Azure Cognitive Services work?

Azure Cognitive Services work by providing developers with pre-built APIs and SDKs that can be integrated into their applications. These APIs and SDKs are designed to be easy to use, even for developers who do not have prior experience with machine learning or AI.

Once integrated into an application, these APIs and SDKs can be used to add intelligent features to the application. For example, the computer vision API can be used to identify objects in images or videos, while the language translation API can be used to translate text from one language to another.

Why use Azure Cognitive Services?

Azure Cognitive Services provides businesses with several benefits, including:

1. Easy to use

One of the main advantages of Azure Cognitive Services is that it is easy to use. The pre-built APIs and SDKs are designed to be simple to integrate into existing applications, even for developers who do not have prior experience with machine learning or AI.

2. Cost-effective

Using Azure Cognitive Services can be more cost-effective than building intelligent features from scratch. With pre-built APIs and SDKs, businesses can save time and money on development costs.

3. Scalability

Azure Cognitive Services is a cloud-based toolset, which means that businesses can scale their applications as needed. This makes it easy to handle increases in traffic or demand without having to worry about infrastructure or hardware.

4. Integration with other Azure services

Azure Cognitive Services can be easily integrated with other Azure services, such as Azure Machine Learning and Azure Stream Analytics. This makes it easy to build end-to-end solutions that leverage the power of AI and machine learning.

Azure Cognitive Services Use Cases

Azure Cognitive Services can be used in a variety of use cases, including:

1. Customer service

Azure Cognitive Services can be used to build intelligent chatbots that can assist customers with their queries. These chatbots can be trained to recognize customer intent and provide relevant responses.

2. Sentiment analysis

Azure Cognitive Services can be used to perform sentiment analysis on social media data, customer feedback, or other unstructured data sources. This can help businesses understand customer sentiment and make informed decisions.

3. Fraud detection

Azure Cognitive Services can be used to detect fraud in financial transactions. The toolset can be used to analyze transaction data and identify patterns that indicate fraudulent activity.

4. Image recognition

Azure Cognitive Services can be used to identify objects in images or videos. This can be useful in a variety of use cases, such as identifying defects in manufacturing or analyzing traffic patterns in cities.

Continue reading

Connect, secure, and simplify your network resources with Azure Virtual Network Manager

Enterprise-scale management and configuration of your network resources in Azure are key to keeping costs down, reducing operational overhead, and properly connecting and securing your network presence in the cloud. We are happy to announce Azure Virtual Network Manager (AVNM), your one-stop shop for managing the connectivity and security of your network resources at scale, is generally available.

What is Azure Virtual Network Manager?

AVNM works through a main process of group, configure, and deploy. You’ll group your network resources across subscriptions, regions, and even tenants; configure the kind of connectivity and security you want among your grouped network resources; and finally, deploy those configurations onto those network groups in whichever and however many regions you’d like.

Common use cases

Common use cases for AVNM include the following and can be addressed by deploying AVNM’s connectivity and security admin configurations onto your defined network groups:

• Interconnected virtual networks (VNets) that communicate directly with each other.
• Central infrastructure services in a hub VNet that are shared by other VNets.
• Establishing direct connectivity between spoke VNets to reduce latency.
• Automatic maintenance of connectivity at scale, even with the addition of new network resources.
• Enforced standard security rules on all existing and new VNets without risk of change.
• Keeping flexibility for VNet owners to configure network security groups (NSGs) as needed for more specific traffic dictation.
• Application of default security rules across an entire organization to mitigate the risk of misconfiguration and security holes.
• Force-allowance of services’ traffic, such as monitoring services and program updates, to prevent accidental blocking through security rules.

Connectivity configuration

Hub and spoke topology

When you have some services in a hub VNet, such as an Azure Firewall or ExpressRoute, and you need to connect several other VNets to that hub to share those services, that means you’ll have to establish connectivity between each of those spoke VNets and the hub. In the future, if you provision new VNets, you’ll also need to make sure those new VNets are correctly connected to the hub VNet.

With AVNM, you can create groups of VNets and select those groups to be connected to your desired hub VNet, and AVNM will establish all the necessary connectivity between your hub VNet and each VNet in your selected groups behind the scenes. On top of the simplicity of creating a hub and spoke topology, new VNets that match your desired conditions can be automatically added to this topology, reducing manual interference from your part.

For the time being, establishing direct connectivity between the VNets within a spoke network group is still in preview and will become generally available (GA) at a later date.

Mesh

If you want all of your VNets to be able to communicate with each other regionally or globally, you can build a mesh topology with AVNM’s connectivity configuration. You’ll select your desired network groups and AVNM will establish connectivity between every VNet that is a part of your selected network groups. The mesh connectivity configuration feature is still in preview and will become generally available at a later date.

How to implement connectivity configurations with existing environments

Let’s say you have a cross-region hub and spoke topology in Azure that you’ve set up through manual peerings. Your hub VNet has an ExpressRoute gateway and your dozens of spoke VNets are owned by various application teams.

Here are the steps you would take to implement and automate this topology using AVNM:

1. Create your network manager.

2. Create a network group for each application team’s respective VNets using Azure Policy definitions that can be conditionally based on parameters including (but not limited to) subscription, VNet tag, and VNet name.

3. Create a connectivity configuration with hub and spoke selected. Select your desired hub VNet and your network groups as the spokes.

4. By default, all connectivity established with AVNM is additive after the connectivity configuration’s deployment. If you’d like AVNM to clean up existing peerings for you, this is an option you can select; otherwise, existing connectivity can be manually cleaned up later if desired.

5. Deploy your hub and spoke connectivity configuration to your desired regions.

In just a few clicks, you’ve set up a hub and spoke topology among dozens of VNets from all application teams globally through AVNM. By defining the conditions of VNet membership for your network groups representing each application team, you’ve ensured that any newly created VNet matching those conditions will automatically be added to the corresponding network group and receive the same connectivity configuration applied onto it. Whether you choose to have AVNM delete existing peerings or not, there is no downtime to connectivity between your spoke VNets and hub VNet.

Security feature

AVNM currently provides you with the ability to protect your VNets at scale with security admin configurations. This type of configuration consists of security admin rules, which are high-priority security rules defined similarly to, but with precedence over NSG rules.

The security admin configuration feature is still in preview and will GA at a later date.

Enforcement and flexibility

With NSGs alone, widespread enforcement on VNets across several applications, teams, or even entire organizations can be tricky. Often there’s a balancing act between attempts at centralized enforcement across an organization and handing over granular, flexible control to teams. The cost of hard enforcement is higher operational overhead as admins need to manage an increasing number of NSGs. The cost of individual teams tailoring their own security rules is the risk of vulnerability as misconfiguration or opened unsafe ports is possible. Security admin rules aim to eliminate this sliding scale of choosing between enforcement and flexibility altogether by providing central governance teams with the ability to establish guardrails, while intentionally allowing traffic for individual teams to flexibly pinpoint security as needed through NSG rules.

Difference from NSGs

Security admin rules are similar to NSG rules in structure and input parameters, but they are not the exact same construct. Let’s boil down these differences and similarities:

	TARGET AUDIENCE	APPLIED ON	EVALUATION ORDER	ACTION TYPES	PARAMETERS
SECURITY ADMIN RULES	Network admins, central governance team	Virtual networks	Higher priority	Allow, Deny, Always Allow	Priority, protocol, action, source, destination
NSG RULES	Individual teams	Subnets, NICs	Lower priority, after security admin rules	Allow, Deny

One key difference is the security admin rule’s Allow type. Unlike its other action types of Deny and Always Allow, if you create a security admin rule to Allow a certain type of traffic, then that traffic will be further evaluated by NSG rules matching that traffic. However, Deny and Always Allow security admin rules will stop the evaluation of traffic, meaning NSGs down the line will not see or handle this traffic. As a result, regardless of NSG presence, administrators can use security admin rules to protect an organization by default.

Key Scenarios

Providing exceptions

Being able to enforce security rules throughout an organization is useful, to say the least. But one of the benefits of security admin rules that we’ve mentioned is its allowance for flexibility by teams within the organization to handle traffic differently as needed. Let’s say you’re a network administrator and you’ve enforced security admin rules to block all high-risk ports across your entire organization, but an application team 1 needs SSH traffic for a few of their resources and has requested an exception for their VNets. You’d create a network group specifically for application team 1’s VNets and create a security admin rule collection targeting only that network group—inside that rule collection, you’d create a security admin rule of action type Allow for inbound SSH traffic (port 22). The priority of this rule would need to be higher than the original rule you created that blocked this port across all of your organization’s resources. Effectively, you’ve now established an exception to the blocking of SSH traffic just for application team 1’s VNets, while still protecting your organization from that traffic by default.

Force-allowing traffic to and from monitoring services or domain controllers

Security admin rules are handy for blocking risky traffic across your organization, but they’re also useful for force-allowing traffic needed for certain services to continue running as expected. If you know that your application teams need software updates for their virtual machines, then you can create a rule collection targeting the appropriate network groups consisting of Always Allow security admin rules for the ports where the updates come through. This way, even if an application team misconfigures an NSG to deny traffic on a port necessary for updates, the security admin rule will ensure the traffic is delivered and doesn’t hit that conflicting NSG.

How to implement security admin configurations with existing environments

Let’s say you have an NSG-based security model consisting of hundreds of NSGs that are modifiable by both the central governance team and individual application teams. Your organization implemented this model originally to allow for flexibility, but there have been security vulnerabilities due to missing security rules and constant NSG modification.

Here are the steps you would take to implement and enforce organization-wide security using AVNM:

1. Create your network manager.

2. Create a network group for each application team’s respective VNets using Azure Policy definitions that can be conditionally based on parameters including (but not limited to) subscription, VNet tag, and VNet name.

3. Create a security admin configuration with a rule collection targeting all network groups. This rule collection represents the standard security rules that you’re enforcing across your entire organization.

4. Create security admin rules blocking high-risk ports. These security admin rules take precedence over NSG rules, so Deny security admin rules have no possibility of conflict with existing NSGs. Redundant or now-circumvented NSGs can be manually cleaned up if desired.

5. Deploy your security admin configuration to your desired regions.

You’ve now set up an organization-wide set of security guardrails among all of your application teams’ VNets globally through AVNM. You’ve established enforcement without sacrificing flexibility, as you’re able to create exceptions for any application team’s set of VNets. Your old NSGs still exist, but all traffic will hit your security admin rules first. You can clean up redundant or avoided NSGs, and your network resources are still protected by your security admin rules, so there is no downtime from a security standpoint.

Source: microsoft.com

Continue reading

Announcing Azure Firewall enhancements for troubleshooting network performance and traffic visibility

IT security administrators are often called on to troubleshoot network issues. For instance, a critical application may exhibit latency or disconnections, frustrating end users. These issues may be caused by a recent routing update or changes in security. In some cases, the cause may be due to a sudden burst in network traffic—overwhelming the network resources.

Read More: SC-900: Microsoft Security, Compliance, and Identity Fundamentals

Microsoft Azure Firewall now offers new logging and metric enhancements designed to increase visibility and provide more insights into traffic processed by the firewall. IT security administrators may use a combination of the following to root cause application performance issues:

o Latency Probe metric is now in preview.

o Flow Trace Log is now in preview.

o Fat Flows Log is now in preview.

Azure Firewall is a cloud-native firewall as a service offering that enables customers to centrally govern and log all their traffic flows using a DevOps approach. The service supports both application and network-level filtering rules and is integrated with the Microsoft Defender Threat Intelligence feed to filter known malicious IP addresses and domains. Azure Firewall is highly available with built-in auto-scaling.

Latency Probe metric—now in preview

In a network infrastructure, one may observe increases in latency depending on various factors. The ability to monitor the latency of the firewall is essential for proactively engaging in any potential issues with traffic or services in the infrastructure.

The Latency Probe metric is designed to measure the overall latency of Azure Firewall and provide insight into the health of the service. IT administrators can use the metric for monitoring and alerting if there is observable latency and diagnosing if the Azure Firewall is the cause of latency in a network.

In the case that Azure Firewall is experiencing latency, this can be due to various reasons, such as high CPU utilization, traffic throughput, or networking issues. As an important note, this tool is powered by Pingmesh technology, which means that the metric measures the average latency of the firewall itself. The metric does not measure end-to-end latency or the latency of individual packets.

Figure 1: Dashboard view of healthy firewall latency measured by the Latency Probe (Preview) metric.

 

Flow Trace logs—now in preview

Azure Firewall logging provides logs for various traffic—such as network, application, and threat intelligence traffic. Today, these logs show traffic through the firewall in the first attempt at a Transmission Control Protocol (TCP) connection, also known as the SYN packet. However, this fails to show the full journey of the packet in the TCP handshake. The ability to monitor and track every packet through the firewall is paramount for identifying packet drops or asymmetric routes.

To dive further into an asymmetric routing example, Azure Firewall—as a stateful firewall—maintains state connections and automatically and dynamically allows traffic to successfully come back to the firewall. However, asymmetric routing can occur when a packet takes one path to the destination through the firewall and takes a different path when attempting to return to the source. This can be due to user misconfiguration, such as adding an unnecessary route in the path of the firewall.

As a result, one can verify if a packet has successfully flowed through the firewall or if there is asymmetric routing by viewing the additional TCP handshake logs in Flow Trace.

To do so, you can monitor network logs to view the first SYN packet and click "enable Flow Trace" to see the additional flags for verification:

o SYN-ACK

o FIN

o FIN-ACK

o RST

o INVALID

By adding these additional flags in Flow Trace logs, IT administrators can now see the return packet, if there was a failed connection, or an unrecognized packet. To enable these logs, please read the documentation linked below.

Figure 2: Flow Trace logs displaying SYN-ACK and FIN packets.

Top Flows—now in preview

Today, Microsoft Azure Firewall Standard can support up to 30 Gbps and Azure Firewall Premium can support up to 100 Gbps of traffic processing. However, in any case, sometimes traffic flows can either be unintentionally or intentionally “heavy” depending on the size, duration, and other factors of the packets. Since these flows can potentially impact other flows and the processing of the firewall, it’s important to monitor these traffic flows, to ensure that the firewall can perform optimally.

The Top Flows log—or industry-known as Fat Flows—log shows the top connections that are contributing to the highest bandwidth in a given time frame through the firewall.

This visibility provides the following benefits for IT administrators:

o Identifying the top traffic flows traversing through the firewall.

o Identifying any unexpected or anomaly traffic.

o Deciding what traffic should be allowed or denied, based on results and goals.

To enable these logs, please read the documentation linked below.

Figure 3: Top Flow logs displaying traffic with the top flow rates.

Source: microsoft.com

Continue reading

Modernize your apps and accelerate business growth with AI

AI has exploded in popularity in recent years, to the point where it’s no longer considered a luxury in the business world, but a necessity. A PricewaterhouseCoopers (PwC) study revealed that the adoption of AI will fuel a 14 percent increase in the global GDP by 2030, representing an additional $15.7 trillion surge to the global economy.

Businesses using AI solutions are discovering new ways to tap into vast amounts of data to get clear insights and accelerate innovation. Thanks to advancements in graphics processing unit (GPU) computational power and the availability of tech services through cloud marketplaces, AI is now more accessible than ever.

As companies look to do more with less, AI will play an increasingly critical role—particularly generative AI, a category of AI algorithms that generate new outputs based on data. Unlike traditional AI systems that are designed to recognize patterns and make predictions, generative AI can analyze large data sets and create entirely new content in a variety of media formats—including text, images, audio, and data—based on what’s described in the input. Generative AI is used in systems like ChatGPT, the powerful natural and language model developed by OpenAI—a global leader in AI research and development.

At Microsoft, we’re committed to democratizing AI and giving you access to advanced generative AI models. As part of that commitment, in 2019, we started a long-term partnership with OpenAI. In January 2023, we announced the third phase of this partnership, including the general availability of Azure OpenAI Service.

With Azure OpenAI Service, businesses can access cutting-edge AI models, including GPT-4 and DALL•E 2. This service is backed by built-in responsible AI and enterprise-grade security. Azure OpenAI Service customers also will have access to ChatGPT—a fine-tuned version of GPT-4 that has been trained and runs inference on Azure AI infrastructure.

Add the power of generative AI to your apps—now available through the ISV Success program

We’re excited to announce that ISV Success program members will now be eligible to apply for access to Azure OpenAI Service. In today’s highly competitive market, ISVs are under intense pressure to differentiate and elevate their app offerings. To gain an edge, many software vendors are tapping into generative AI to modernize their applications.

With AI-optimized infrastructure and tools, Azure OpenAI Service empowers developers to build and modernize apps through direct access to OpenAI models. These generative AI models offer a deep understanding of language and code to enable apps with new reasoning and comprehension capabilities, which can be applied to a variety of use cases, such as code generation, content summarization, semantic search, and natural language-to-code translation.

As a participant in the program, you will also get access to advanced AI services like custom neural voice, speaker recognition, and content filters.

Source: microsoft.com

Continue reading

Enhanced Azure Arc integration with Datadog simplifies hybrid and multicloud observability

Businesses today are managing complex, distributed environments and need a ubiquitous computing platform for all workloads that can meet them where they are. We’ve seen an increasing need for customers to not only deploy, manage, and operate across on-premises and one or more clouds, but also to have better visibility and insights across all IT investments spanning cloud to edge.

Today, we’re delivering improved observability and management with the general availability of our enhanced Microsoft Azure Arc integration with Datadog. Building on our established collaboration, we are natively integrating Datadog with Azure Arc to meet customers where they are and provide rich insights from Azure Arc–enabled resources directly into Datadog dashboards. Customers can monitor real-time data during cloud migrations and performance of applications running both in the public cloud and in hybrid or multicloud environments.

Benefits of Azure Arc integration with Datadog

With the Azure Arc integration with Datadog, customers can:

◉ Monitor the connection status and agent version of Azure Arc–enabled servers, wherever they are running.

◉ Automatically add Azure tags to associated hosts in Datadog for additional context.

◉ Identify which Azure Arc–enabled servers have the Datadog Agent installed.

◉ Deploy the Datadog Agent onto your Azure Arc–enabled servers as an extension.

◉ Get unified billing for the Datadog service through Azure subscription invoicing.

Datadog is a cloud-scale monitoring and security platform for large-scale applications that aggregates data across your entire stack with more than 600 integrations for centralized visibility and faster troubleshooting on dynamic architectures. This provides developers and operations teams observability into every layer of their applications on Azure, so they diagnose performance issues quickly.

When Datadog first became an Azure Native ISV Service, it allowed customers to streamline their experience for purchasing, configuring, and managing Datadog directly inside the Azure portal. It reduced the learning curve for using Datadog to monitor the health and performance of your applications in Azure and sets customers up for a successful cloud migration or modernization.

For many customers, hybrid deployments are a durable and long-term strategy due to factors such as latency and compliance requirements, and we are committed to meeting customers wherever they are. With Azure Arc, we provide a consistent set of tools and services for customers to extend cloud technology across your distributed infrastructure. More than 12,000 customers are using Azure Arc, double the number a year ago. By partnering with organizations like Datadog, we are unlocking even more innovation and bringing Azure services into the tools our customers are already using.

Enhanced Azure Arc integration features

Features available with today’s general availability include:

Monitor the Arc connection status and agent version

Customers can easily identify any Azure Arc–enabled resources that are not in a connected state. You can also set up Datadog monitors to alert you immediately if the connection is unhealthy. Before this new integration, Azure Arc resources would look like any other virtual machine on-premises or in Azure. Now, you can access critical metadata to ensure your Azure Arc–enabled Windows and Linux servers, SQL servers, and Kubernetes clusters are secured and connected. IT operators will be able to troubleshoot much faster if a resource is disconnected and can quickly restore the connectivity to Azure Arc.

Datadog can also show which hosts are running an older version of Azure Arc. It then becomes easy to update the agent using Azure Update Management and utilize Azure Automation for latest updates to the Azure Arc agent whenever there is a new version.

Automatically add Azure tags for easy management and compliance tracking

A popular benefit of Azure Arc is using tags in Azure Resource Manager. Many organizations tag on-premises resources by cost center or datacenter server groups that are subject to specific regulations or requirements. Tags also create an audit trail to help trace the history of a particular resource and identify potential security issues when performing audits.

With the Azure Arc integration, Datadog can build rich visualizations and actionable alerts using the tags you have already created for Azure Arc–enabled resources. Now, when you perform patching or updates for Azure Arc–enabled servers, you get much richer insights to help validate software patches and troubleshoot application issues.

Easily identify which Azure Arc–enabled servers have the Datadog Agent

Azure Arc brings your hybrid and multicloud servers, Kubernetes clusters, and data services into a single dashboard for seamless management between environments. Aside from grouping resources with Azure Resource Manager, Azure Arc–enabled resources benefit from Azure role-based access control (RBAC), so different IT and developer teams can easily delegate access to their applications. For a centralized IT monitoring team, you can now ensure your Azure Arc–enabled resources have the Datadog Agent by cross-referencing these servers with agent data to get a real-time view of which Arc resources have Datadog Agent reporting.

Source: microsoft.com

Continue reading

Powerful Microsoft MB-910 Exam Preparation Strategies Everyone Should Know

For businesses to make money, they need to know how to communicate with their customers and potential customers effectively. To improve their communication strategies, businesses use software and applications to keep track of important information that could make a big difference in whether or not they make a sale. One such application is Microsoft Dynamics 365, which is a cloud-based suite of business tools that includes elements of both an Enterprise Resource Planning system (ERP) and a Customer Relationship Management (CRM) system. If you’re looking to establish yourself as a leader in the CRM field, getting certified in MB-910: Microsoft Dynamics 365 Fundamentals (CRM) can be a valuable asset.

Overview of Microsoft Dynamics 365 Fundamentals (CRM) MB-910 Exam

This certification is designed for people who want to prove that they have the expertise and practical experience working with the customer engagement applications of Microsoft Dynamics 365.

To increase their chances of success in obtaining this certification, candidates are recommended to have prior experience in IT, customer engagement, and business operations.

The Microsoft Dynamics 365 Fundamentals (CRM) exam, also known as MB-910, will consist of 40-60 questions answerable in 60 minutes. The exam questions are of different types, such as case studies, short answers, multiple-choice, mark review, drag and drop, and more. To pass the exam, you must score at least 700 out of a possible 1000 points. The cost of the MB-910 exam is $99 USD, including additional taxes. The exam is available only in English, Japanese, Chinese (Simplified), Korean, French, Spanish, Portuguese (Brazil), Russian, Arabic (Saudi Arabia), Chinese (Traditional), Italian, and German languages.

Target Audience

Individuals at different levels of their professional journey and working in various roles can gain advantages from this basic course. Here are some instances:

IT experts who aim to demonstrate a basic comprehension of the software they use.

Business representatives and other individuals who have knowledge of Dynamics 365 and seek to authenticate their abilities and expertise.

Developers who wish to showcase their comprehension of customer relationship management and business operations.

Individuals such as students, fresh graduates, or career changers aspire to utilize Dynamics 365 customer engagement features to advance their careers.

How to Prepare for the Microsoft MB-910 Exam?

Preparation is a crucial element when it comes to passing an exam. Even if you have extensive experience, it is beneficial to familiarize yourself with the content, characteristics, and strategies of the specific test you intend to take. If you are planning to take the Microsoft Dynamics 365 Fundamentals (CRM) MB-910 exam, this article provides some helpful tips to help you get ready. Let’s take a closer look at them.

Review the study guide, comprehend the exam goals, and establish a study schedule to ensure that you do not procrastinate and leave everything to the last minute.

Next, select Microsoft’s learning path and delve further into the main areas and subtopics. Watch the instructor-led videos to gain a better understanding of the subject.

Once you feel self-assured about your preparation, proceed to the MB-910 sample questions. There are numerous practice tests available that serve as a platform for this Microsoft certification exam. Use them to evaluate your progress, identify areas of improvement, and attempt the test again until you are satisfied with your performance.

Review your score on practice tests. Once you score more than 90% in practice tests, register for the actual exam and add a significant accomplishment to your credentials.

Benefits of Taking the MB-910 Practice Test

Taking MB-910 practice tests is like sowing a seed, which will eventually allow you to reap the benefits of achieving your desired score and obtaining the Microsoft Certified - Dynamics 365 Fundamentals (CRM) certification. When investing time and effort into something, it is natural to wonder about the benefits. So, what exactly can you gain from taking MB-910 practice tests?

Apart from helping you pinpoint your areas of weakness and strength, taking MB-910 practice tests will give you a more accurate perception of the actual exam questions. This is, of course, on the condition that you regularly take one or two MB-910 practice tests since it’s impossible to become familiar with something after just one attempt unless you possess a photographic memory.

Another advantage of taking MB-910 practice tests is the ability to create a personalized and effective study schedule to achieve a realistic score. As previously stated, these practice tests will give you an idea of the format of the actual exam. As a result, you can approach the real exam more confidently because you are already familiar with its structure. TRY OUT FREE MB-910 SAMPLE QUESTIONS NOW!

Conclusion

If you follow the exam preparation strategies we have provided for Microsoft MB-910, you will likely achieve a good result. You can make your preparation even more effective by taking practice tests and utilizing the feedback you receive to improve further. Keep in mind that learning the strategies is not enough; you need to take action and implement them. Taking action will demonstrate your commitment to passing the exam. So, take action and see how well these strategies work for you!

Continue reading

Monitor Azure Virtual Network Manager changes with event logging

Today, our customers establish and manage their Azure virtual networks at scale. As their number of network resources grows, the question of how to maintain connectivity and security among their scale of resources arises. This is where Microsoft Azure Virtual Network Manager comes in—your one-stop shop for managing the connectivity and security of your network resources at scale (currently in preview). And when customers use Azure Virtual Network Manager, they also need visibility into what kind of changes were made so that they can audit those events, analyze those changes over time, and debug issues along the way. This capability is now a reality—Azure Virtual Network Manager event logging is now in preview.

Azure Virtual Network Manager (AVNM) uses Azure Monitor for telemetry collection and analysis like many other Azure services. AVNM now provides event logs that you can interact with through Azure Monitor’s Log Analytics tool in the Azure Portal, as well as through a storage account. You can also send these logs to an event hub or partner solution.

With this preview announcement, Azure Virtual Network Manager will provide a log category for network group membership change. In the context of AVNM, network groups are defined by the user to contain virtual networks. The membership of a network group can be manually provided (such as by selecting VNetA, VNetB, and VNetC to be a part of this network group) as well as conditionally set through Azure Policy (such as by defining that any virtual network within a certain subscription that contains some string in its name will be added to this network group). The network group membership change log category tracks when a particular virtual network is added to or removed from a network group. This can be used to track network group membership changes over time, to capture a snapshot of a particular virtual network’s network group membership, and more.

What attributes are part of this event log category?

This network group membership change category emits one log per network group membership change. So, when a virtual network is added to or removed from a network group, a log is emitted correlating to that single addition or removal for that particular virtual network. If you’re looking at one of these logs from your storage account, you’ll see several attributes:

Attribute	Description
time	Datetime when the event was logged.
resourceId	Resource ID of the network manager.
location	Location of the virtual network resource.
operationName	Operation that resulted in the virtual network being added or removed. Always the “Microsoft.Network/virtualNetworks/networkGroupMembership/write” operation.
category	Category of this log. Always “NetworkGroupMembershipChange.”
resultType	Indicates successful or failed operation.
correlationId	GUID that can help relate or debug logs.
level	Always “Info.”
properties	Collection of properties of the log.

Within the properties attribute are several nested attributes:

Properties attribute	Description
Message	Basic success or failure message.
MembershipId	Default membership ID of the virtual network.
GroupMemberships	Collection of what network groups the virtual network belongs to. There may be multiple “NetworkGroupId” and “Sources” listed within this property since a virtual network can belong to multiple network groups simultaneously.
MemberResourceId	Resource ID of the virtual network that was added to or removed from a network group.

Within the GroupMemberships attribute are several nested attributes:

GroupMemberships attribute	Description
NetworkGroupId	ID of a network group the virtual network belongs to.
Sources	Collection of how the virtual network is a member of the network group.

Within the Sources attribute are several nested attributes:

 

Sources attribute	Description
Type	Denotes whether the virtual network was added manually (“StaticMembership”) or conditionally via Azure Policy (“Policy”).
StaticMemberId	If the “Type” value is “StaticMembership,” this property will appear.
PolicyAssignmentId	If the “Type” value is “Policy,” this property will appear. ID of the Azure Policy assignment that associates the Azure Policy definition to the network group.
PolicyDefinitionId	If the “Type” value is “Policy,” this property will appear. ID of the Azure Policy definition that contains the conditions for the network group’s membership.

How do I get started?

The first step you’ll need to take is to set up your Log Analytics workspace or your storage account, depending on how you want to consume these event logs. You should note that if you’re using a storage account or event hub, it will need to be in the same region of the network manager you’re accessing logs from. If you’re using a Log Analytics workspace, it can be in any region. The network manager you’re accessing the logs of won’t need to belong to the same subscription as your Log Analytics workspace or storage account, but permissions may restrict your ability to access logs cross-subscription.

Note that at least one virtual network must be added or removed from a network group in order to generate logs. A log will generate for this event a couple minutes later.

Accessing Azure Virtual Network Manager’s event logs with Log Analytics

The first step is to navigate to your desired network manager and select the Diagnostic settings blade under the Monitoring section. Then you can select Add diagnostic setting and select the option to send the logs to your Log Analytics workspace.

Then you can navigate to your Log Analytics workspace directly through your network manager by selecting the Logs blade under the Monitoring section.

Alternatively, you can also navigate to your Log Analytics workspace in the Azure Portal and select the Logs blade.

From either place, you can run your own queries on your network manager’s emitted logs for network group membership changes, or you can also run our preloaded queries. Our preloaded queries can fetch the most recent network group membership changes and failed network group membership changes.

Accessing Azure Virtual Network Manager’s event logs with a storage account

The first step is to again navigate to your desired network manager and select the Diagnostic settings blade under the Monitoring section. Then you can select Add diagnostic setting and select the option to archive the logs to your storage account.

Then you can navigate to your storage account and select the Storage browser blade.

Select Blob containers. A blob container will be automatically generated once network group membership changes occur.

Navigate down the blob container’s file path until you reach a JSON file for the datetime specified by that file path.

Download the JSON file to view the raw logs for the file path’s datetime.

Source: microsoft.com

Continue reading