this update take much problems in my pc such as when I using MS edge in that my cursor is loading someting and task bar and many more also disappears . can any one help me to fix it ?

​this update take much problems in my pc such as when I using MS edge in that my cursor is loading someting and task bar and many more also disappears . can any one help me to fix it ?  Read More

​

the measuring tool in visio, when i bring it onto the page and try to use it…it freezes up, the horizontal and vertical work fine but when try to use the measuring tool for angle measurements it just freezes up and i have to restart the program

​the measuring tool in visio, when i bring it onto the page and try to use it…it freezes up, the horizontal and vertical work fine but when try to use the measuring tool for angle measurements it just freezes up and i have to restart the program  Read More

​

Hello Microsoft DFP Customers, 

We’re excited to share some answers to commonly asked questions about D365 Fraud Protection (DFP)! Each week, we intend to spotlight a particular topic to help you maximize the benefit of our product and post the answers to questions here. This week, we’re diving into DFP ‘Rules’.  

Should you have any questions regarding the commonly asked Q&A provided, please do not hesitate to reach out here in the Fraud Protection Tech Community. Your feedback is incredibly valuable to us, and we genuinely appreciate your ongoing collaboration.

Best regards,

DFP Product Team

——————

1. What are the different inputs that can be passed into rules?  

In Microsoft Dynamics 365 Fraud Protection, you can create rules that utilize various inputs to convert an assessment into a decision, such as Approve, Reject, Review, or Challenge. The inputs for these rules can include:  

Attributes sent in the API request for the assessment, including custom data which can be accessed with the @ operator. For example, @”user.userId”.  

Scores generated from Fraud Protection’s artificial intelligence models, such as @”riskscore”.  

Lists that you have uploaded to Fraud Protection. You can reference these lists in your rules after uploading them.  

Velocities that you have defined in Fraud Protection to perform velocity checks.  

External calls that you have created in Fraud Protection.  
Functions that you have created within Fraud Protection.  

References:  

Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn  

2. Why did a particular transaction not hit rule ‘X’?  

There could be several reasons why a transaction did not trigger a specific rule (Rule X) in Microsoft Dynamics 365 Fraud Protection. Here are some common factors to consider:  

Rule Configuration: Ensure that Rule X is correctly configured with the appropriate conditions and logic. If the conditions are not met, the rule will not trigger.  

Rule Order: The order of rules matters. If Rule X is lower in the order and a previous rule has already made a decision on the transaction, Rule X may not be evaluated.  

Rule Scope: Check if Rule X is scoped correctly to apply to the transaction in question. It might be limited to certain types of transactions or channels.  

Data Availability: The necessary data to evaluate Rule X must be present in the transaction. If the required data is missing or incorrect, the rule may not trigger.  

Rule Status: Verify that Rule X is active and not disabled or in ‘observe’ mode, which would prevent it from taking action on transactions.  

For a specific transaction, you can review the Rule analyst reports and Summary report in Dynamics 365 Fraud Protection, which provide insights into the transaction volume, rule decision distributions, and the impact of rules that you’ve enabled [1][2]. These reports can help you understand why Rule X did not trigger for a particular transaction.  

If you’re still unable to determine why Rule X did not hit, you may need to consult with your Dynamics 365 Fraud Protection support team or review the service logs for more detailed information. There might have been a recent update or an issue escalated that could be related to the rule’s behavior.  

References:  

[1] Rule analyst reports – Dynamics 365 Fraud Protection | Microsoft Learn  

[2] Summary report – Dynamics 365 Fraud Protection | Microsoft Learn  

3. Why do we need to set up rules if the score can help evaluate risk?  

In Microsoft Dynamics 365 Fraud Protection, while the score generated by the AI model provides a valuable assessment of risk, setting up rules is crucial for several reasons:  

Customization: Rules allow you to tailor the fraud protection system to your specific business needs and risk appetite. You can create rules that threshold the score to make decisions that suit your business, such as approving transactions below a certain score and challenging or rejecting those above it.  

Complex Scenarios: Scores alone may not capture the complexity of certain fraud scenarios. Rules can incorporate additional parameters from the transaction payload, enabling you to detect business policy violations or emerging fraud patterns specific to your business.  

Control: Rules give you control over the decision-making process. You can define what actions to take based on the score and other attributes, such as triggering MFA or reviewing transactions from certain geographies.  

Adaptability: Fraud patterns evolve, and rules can be quickly adjusted to respond to new threats, whereas model retraining for scores might take longer.  

Segmentation: You can segment your traffic and set custom score cutoffs for different segments, optimizing fraud control for various product lines or transaction types .  

For a more detailed understanding of the role of rules in fraud protection, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn which provides comprehensive guidance on rule management within the system.

4. What rule can help catch more fraud based on past data?  

In Microsoft Dynamics 365 Fraud Protection, transactions with the highest risk scores are those that are most likely to be fraudulent. The common rules applied to these transactions are designed to identify and prevent high-risk activities. Here are some of the rules that are commonly used:  

Threshold rules: These rules reject transactions that exceed a certain risk score. For example, transactions for gift cards might be rejected if the risk score is above 400.  

Velocity rules: These rules identify and block rapid, repeated transactions from the same entity, which could indicate fraudulent behavior.  

List checks: These rules compare transaction data against lists of known fraud indicators, such as device fingerprints or IP addresses.  

Anomaly detection: These rules look for patterns of behavior that are unusual and deviate from the norm, which could indicate fraud.  

For a more detailed understanding of the common rules applied to high-scoring transactions, you may want to review the “Score analyst reports” in the Dynamics 365 Fraud Protection portal, which can provide insights into the relationship between Fraud Protection scores and the rules that were executed. If you need further assistance or have specific questions you can also contact Microsoft support or your Microsoft authorized partner for additional assistance.  

References:  

Score analyst reports – Dynamics 365 Fraud Protection | Microsoft Learn  

How does inheritance work for rules?  

5. How does inheritance work for rules?  

In Microsoft Dynamics 365 Fraud Protection, rule inheritance works within a multi-environment hierarchy. If your Fraud Protection instance has multiple environments, you can manage rules in a specific environment using the environment switcher. Rules in the top-level parent environment are evaluated first. If the rule settings for the top-level parent environment are set to “Run all matching rules until a decision is made,” the rules in the second-level parent environment are evaluated next. This process continues unless the rule settings for an environment are set to “Run only the first matching rule,” or until all the rules for the parent environment and the current environment are evaluated [1].  

However, it’s important to note that all resources, such as velocities, external calls, lists, and external assessments, are always local to an environment. Even in a hierarchy, resources defined in a parent environment are not inherited for use in rules in child environments. They are inherited for aggregation purposes but not for use in rules. For example, a velocity defined in a parent environment would increment based on transactions to a child environment, but if you wanted to reference that velocity in a rule, the rule would have to be in the same (parent) environment [2].  

For functions, you can create them in any environment in the multi-hierarchy stack. When a function references resources available in the environment, the lower environments that invoke the function also inherit the resources that the function references   

For a more detailed understanding of how inheritance works for rules in Microsoft Dynamics 365 Fraud Protection, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn   
  

References  

[1] Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn  

[2] Functions – Dynamics 365 Fraud Protection | Microsoft Learn  

6. How often should we revisit the rule and make adjustment?  

In Microsoft Dynamics 365 Fraud Protection, it’s important to regularly revisit and adjust rules to ensure they remain effective against evolving fraud patterns. While there is no one-size-fits-all answer, here are some best practices:  

Regular Review: Rules should be reviewed on a regular basis, such as monthly or quarterly, to ensure they align with current fraud trends and business strategies.  

Performance Analysis: Utilize the Rule analyst reports to monitor the performance and impact of your rules. Adjustments may be necessary if you notice changes in fraud patterns or false positive rates.  

After Major Events: Review and potentially adjust rules after major events such as product launches, holiday seasons, or known fraud attacks, as these can change the fraud landscape significantly.  

Feedback Loop: Incorporate feedback from customer service and fraud investigation teams into your rule adjustments to address any new types of fraud they are encountering.  

It’s also beneficial to stay informed about updates to Dynamics 365 Fraud Protection features and capabilities, as new functionalities may offer additional ways to enhance your rules and fraud protection strategies.   

References:  

Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn  

7. How do I create a rule based on ASN attribute  

To create a rule based on the ASN (Autonomous System Number) attribute in Microsoft Dynamics 365 Fraud Protection, you would typically use the ASN as part of the condition in a WHEN statement within the rule definition. Here’s a quick guide on how to do it:  

Identify the ASN attribute: Determine the ASN attribute from the transaction data that you want to use in your rule. This could be part of the device information or network data.  

Access the Rules Editor: Go to the Dynamics 365 Fraud Protection portal and navigate to the rules editor section.  

Create a New Rule or Edit an Existing One: You can either create a new rule or edit an existing one to include the ASN attribute in the conditions.  

Define the Rule: Use the RETURN and WHEN keywords to define your rule. The basic structure of a rule is as follows:  

RETURN <decision> WHEN <condition>  
  

For example, if you want to flag transactions from a specific ASN for review, your rule might look like this:  

RETURN Review(“Suspicious ASN”) WHEN @”network.asn” == “12345”  

Replace “12345” with the actual ASN you want to monitor.  

Test the Rule: Before activating the rule, test it to ensure it works as expected and does not impact legitimate transactions.  

Activate the Rule: Once you are satisfied with the rule’s performance, activate it to start using it for real-time transaction assessments.  

You can also use the visual mode in the rules editor for an easier rule creation experience, where you can select attributes from a drop-down menu and add multiple filters to a clause.  

For more detailed instructions and best practices on rule creation, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.  

8. How do I create a velocity-based rule?  

Creating a velocity-based rule in Microsoft Dynamics 365 Fraud Protection involves defining velocities that monitor the frequency of events from a user or entity, which can indicate suspicious activity and potential fraud. Here’s a step-by-step guide on how to create a velocity-based rule:  

Define a Velocity: Velocities are defined using the SELECT, FROM, WHEN, and GROUPBY keywords. Here’s the structure you would use:  

SELECT <aggregation method> AS <velocity name>  
FROM <event type>  
WHEN <condition>  
GROUPBY <attribute name>  
  

For example, to define a velocity that counts the number of purchases from a specific IP address, you might use:  

SELECT Count() AS numPurchases  
FROM Purchase  
WHEN @”device.ipAddress” == “192.168.1.1”  
GROUPBY @”device.ipAddress”  
  

Create a Velocity Set: In the Fraud Protection portal, navigate to the Velocities section and select ‘New velocity set’. Define your velocities within this set.  

Publish the Velocity: After defining your velocity, you need to publish it so it can be used in rules.  

Create a Rule Using the Velocity: Now that you have a defined velocity, you can create a rule that uses this velocity. In the rules editor, you would reference the velocity in a WHEN clause of a rule. For example:  

RETURN Review(“High number of purchases”) WHEN numPurchases > 5  

Test and Activate the Rule: Before activating the rule, test it to ensure it works as expected. Once you’re satisfied, activate the rule for it to take effect on real-time transaction assessments.  

For more detailed instructions, you can refer to the official documentation on Perform velocity checks – Dynamics 365 Fraud Protection | Microsoft Learn.  

9. How do I create an IP-based rule?  

Creating an IP-based rule in Microsoft Dynamics 365 Fraud Protection involves using the IP address as a condition within the rule’s logic. Here’s a general guide on how to create an IP-based rule:  

Access the Rules Editor: Navigate to the Dynamics 365 Fraud Protection portal and open the rules editor.  

Define the Rule: Use the RETURN and WHEN keywords to define your rule. The basic structure of a rule is as follows:  

RETURN <decision> WHEN <condition>  

For an IP-based rule, your condition will involve the IP address attribute. For example:  

RETURN Reject(“Suspicious IP”) WHEN @”device.ipAddress” == “192.168.1.1”  

Replace “192.168.1.1” with the actual IP address you want to monitor.  

Test the Rule: Before activating the rule, test it to ensure it correctly identifies transactions based on the IP address without impacting legitimate transactions.  

Activate the Rule: Once you’re satisfied with the rule’s performance, activate it to start using it for real-time transaction assessments.  

For more detailed instructions, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.  

10. Can you recommend the rule structure for MFA flow?  

In Microsoft Dynamics 365 Fraud Protection, setting up a rule structure for Multi-Factor Authentication (MFA) flow would typically involve creating rules that trigger MFA challenges based on certain conditions. Here’s a recommended structure for such a rule:  

Define the Condition: Identify the conditions under which you want to trigger MFA. This could be based on risk scores, user behavior, transaction details, or other attributes.  

Create the Rule: Use the RETURN and WHEN keywords to define your rule. The basic structure of a rule is:  

RETURN <decision> WHEN <condition>  
  

For example, if you want to challenge a login attempt when the risk score is high, your rule might look like this:  

RETURN Challenge(“MFA Required”) WHEN @”riskscore” > 800  
  

Test the Rule: Before activating the rule, test it to ensure it correctly identifies scenarios for MFA without impacting legitimate users.  

Activate the Rule: Once you’re satisfied with the rule’s performance, activate it to start using it for real-time assessments.  

For more detailed instructions, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.  

​Hello Microsoft DFP Customers, 
 
We’re excited to share some answers to commonly asked questions about D365 Fraud Protection (DFP)! Each week, we intend to spotlight a particular topic to help you maximize the benefit of our product and post the answers to questions here. This week, we’re diving into DFP ‘Rules’.  
 
Should you have any questions regarding the commonly asked Q&A provided, please do not hesitate to reach out here in the Fraud Protection Tech Community. Your feedback is incredibly valuable to us, and we genuinely appreciate your ongoing collaboration.
 
Best regards,
DFP Product Team
 
——————
 
1. What are the different inputs that can be passed into rules?  
 
In Microsoft Dynamics 365 Fraud Protection, you can create rules that utilize various inputs to convert an assessment into a decision, such as Approve, Reject, Review, or Challenge. The inputs for these rules can include:  

Attributes sent in the API request for the assessment, including custom data which can be accessed with the @ operator. For example, @”user.userId”.  

Scores generated from Fraud Protection’s artificial intelligence models, such as @”riskscore”.  

Lists that you have uploaded to Fraud Protection. You can reference these lists in your rules after uploading them.  

Velocities that you have defined in Fraud Protection to perform velocity checks.  

External calls that you have created in Fraud Protection.  
Functions that you have created within Fraud Protection.  

References:  

Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn  

 
 
 
2. Why did a particular transaction not hit rule ‘X’?  
There could be several reasons why a transaction did not trigger a specific rule (Rule X) in Microsoft Dynamics 365 Fraud Protection. Here are some common factors to consider:  

Rule Configuration: Ensure that Rule X is correctly configured with the appropriate conditions and logic. If the conditions are not met, the rule will not trigger.  

Rule Order: The order of rules matters. If Rule X is lower in the order and a previous rule has already made a decision on the transaction, Rule X may not be evaluated.  

Rule Scope: Check if Rule X is scoped correctly to apply to the transaction in question. It might be limited to certain types of transactions or channels.  

Data Availability: The necessary data to evaluate Rule X must be present in the transaction. If the required data is missing or incorrect, the rule may not trigger.  

Rule Status: Verify that Rule X is active and not disabled or in ‘observe’ mode, which would prevent it from taking action on transactions.  

  
For a specific transaction, you can review the Rule analyst reports and Summary report in Dynamics 365 Fraud Protection, which provide insights into the transaction volume, rule decision distributions, and the impact of rules that you’ve enabled [1][2]. These reports can help you understand why Rule X did not trigger for a particular transaction.  
  
If you’re still unable to determine why Rule X did not hit, you may need to consult with your Dynamics 365 Fraud Protection support team or review the service logs for more detailed information. There might have been a recent update or an issue escalated that could be related to the rule’s behavior.  
  
References:  
[1] Rule analyst reports – Dynamics 365 Fraud Protection | Microsoft Learn  
[2] Summary report – Dynamics 365 Fraud Protection | Microsoft Learn  
 
 
 
3. Why do we need to set up rules if the score can help evaluate risk?  
In Microsoft Dynamics 365 Fraud Protection, while the score generated by the AI model provides a valuable assessment of risk, setting up rules is crucial for several reasons:  

Customization: Rules allow you to tailor the fraud protection system to your specific business needs and risk appetite. You can create rules that threshold the score to make decisions that suit your business, such as approving transactions below a certain score and challenging or rejecting those above it.  

Complex Scenarios: Scores alone may not capture the complexity of certain fraud scenarios. Rules can incorporate additional parameters from the transaction payload, enabling you to detect business policy violations or emerging fraud patterns specific to your business.  

Control: Rules give you control over the decision-making process. You can define what actions to take based on the score and other attributes, such as triggering MFA or reviewing transactions from certain geographies.  

Adaptability: Fraud patterns evolve, and rules can be quickly adjusted to respond to new threats, whereas model retraining for scores might take longer.  

Segmentation: You can segment your traffic and set custom score cutoffs for different segments, optimizing fraud control for various product lines or transaction types .  

  
For a more detailed understanding of the role of rules in fraud protection, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn which provides comprehensive guidance on rule management within the system.
 
 
 
4. What rule can help catch more fraud based on past data?  
In Microsoft Dynamics 365 Fraud Protection, transactions with the highest risk scores are those that are most likely to be fraudulent. The common rules applied to these transactions are designed to identify and prevent high-risk activities. Here are some of the rules that are commonly used:  

Threshold rules: These rules reject transactions that exceed a certain risk score. For example, transactions for gift cards might be rejected if the risk score is above 400.  

Velocity rules: These rules identify and block rapid, repeated transactions from the same entity, which could indicate fraudulent behavior.  

List checks: These rules compare transaction data against lists of known fraud indicators, such as device fingerprints or IP addresses.  

Anomaly detection: These rules look for patterns of behavior that are unusual and deviate from the norm, which could indicate fraud.  

  
For a more detailed understanding of the common rules applied to high-scoring transactions, you may want to review the “Score analyst reports” in the Dynamics 365 Fraud Protection portal, which can provide insights into the relationship between Fraud Protection scores and the rules that were executed. If you need further assistance or have specific questions you can also contact Microsoft support or your Microsoft authorized partner for additional assistance.  
  
References:  

Score analyst reports – Dynamics 365 Fraud Protection | Microsoft Learn  

How does inheritance work for rules?  
 
 
 
5. How does inheritance work for rules?  
In Microsoft Dynamics 365 Fraud Protection, rule inheritance works within a multi-environment hierarchy. If your Fraud Protection instance has multiple environments, you can manage rules in a specific environment using the environment switcher. Rules in the top-level parent environment are evaluated first. If the rule settings for the top-level parent environment are set to “Run all matching rules until a decision is made,” the rules in the second-level parent environment are evaluated next. This process continues unless the rule settings for an environment are set to “Run only the first matching rule,” or until all the rules for the parent environment and the current environment are evaluated [1].  
  
However, it’s important to note that all resources, such as velocities, external calls, lists, and external assessments, are always local to an environment. Even in a hierarchy, resources defined in a parent environment are not inherited for use in rules in child environments. They are inherited for aggregation purposes but not for use in rules. For example, a velocity defined in a parent environment would increment based on transactions to a child environment, but if you wanted to reference that velocity in a rule, the rule would have to be in the same (parent) environment [2].  
  
For functions, you can create them in any environment in the multi-hierarchy stack. When a function references resources available in the environment, the lower environments that invoke the function also inherit the resources that the function references   
  
For a more detailed understanding of how inheritance works for rules in Microsoft Dynamics 365 Fraud Protection, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn     
References  

[1] Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn  

[2] Functions – Dynamics 365 Fraud Protection | Microsoft Learn  

 
 
 
6. How often should we revisit the rule and make adjustment?  
In Microsoft Dynamics 365 Fraud Protection, it’s important to regularly revisit and adjust rules to ensure they remain effective against evolving fraud patterns. While there is no one-size-fits-all answer, here are some best practices:  

Regular Review: Rules should be reviewed on a regular basis, such as monthly or quarterly, to ensure they align with current fraud trends and business strategies.  

Performance Analysis: Utilize the Rule analyst reports to monitor the performance and impact of your rules. Adjustments may be necessary if you notice changes in fraud patterns or false positive rates.  

After Major Events: Review and potentially adjust rules after major events such as product launches, holiday seasons, or known fraud attacks, as these can change the fraud landscape significantly.  

Feedback Loop: Incorporate feedback from customer service and fraud investigation teams into your rule adjustments to address any new types of fraud they are encountering.  

  
It’s also beneficial to stay informed about updates to Dynamics 365 Fraud Protection features and capabilities, as new functionalities may offer additional ways to enhance your rules and fraud protection strategies.   
  
References:  

Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn  

 
 
 
7. How do I create a rule based on ASN attribute  
To create a rule based on the ASN (Autonomous System Number) attribute in Microsoft Dynamics 365 Fraud Protection, you would typically use the ASN as part of the condition in a WHEN statement within the rule definition. Here’s a quick guide on how to do it:  

Identify the ASN attribute: Determine the ASN attribute from the transaction data that you want to use in your rule. This could be part of the device information or network data.  

Access the Rules Editor: Go to the Dynamics 365 Fraud Protection portal and navigate to the rules editor section.  

Create a New Rule or Edit an Existing One: You can either create a new rule or edit an existing one to include the ASN attribute in the conditions.  

Define the Rule: Use the RETURN and WHEN keywords to define your rule. The basic structure of a rule is as follows:  

RETURN <decision> WHEN <condition>    
For example, if you want to flag transactions from a specific ASN for review, your rule might look like this:  
RETURN Review(“Suspicious ASN”) WHEN @”network.asn” == “12345”  
  
Replace “12345” with the actual ASN you want to monitor.  

Test the Rule: Before activating the rule, test it to ensure it works as expected and does not impact legitimate transactions.  

Activate the Rule: Once you are satisfied with the rule’s performance, activate it to start using it for real-time transaction assessments.  

  
You can also use the visual mode in the rules editor for an easier rule creation experience, where you can select attributes from a drop-down menu and add multiple filters to a clause.  
  
For more detailed instructions and best practices on rule creation, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.  
 
 
 
 
8. How do I create a velocity-based rule?  
Creating a velocity-based rule in Microsoft Dynamics 365 Fraud Protection involves defining velocities that monitor the frequency of events from a user or entity, which can indicate suspicious activity and potential fraud. Here’s a step-by-step guide on how to create a velocity-based rule:  

Define a Velocity: Velocities are defined using the SELECT, FROM, WHEN, and GROUPBY keywords. Here’s the structure you would use:  

SELECT <aggregation method> AS <velocity name>  FROM <event type>  WHEN <condition>  GROUPBY <attribute name>    
For example, to define a velocity that counts the number of purchases from a specific IP address, you might use:  
SELECT Count() AS numPurchases  FROM Purchase  WHEN @”device.ipAddress” == “192.168.1.1”  GROUPBY @”device.ipAddress”    

Create a Velocity Set: In the Fraud Protection portal, navigate to the Velocities section and select ‘New velocity set’. Define your velocities within this set.  

Publish the Velocity: After defining your velocity, you need to publish it so it can be used in rules.  

Create a Rule Using the Velocity: Now that you have a defined velocity, you can create a rule that uses this velocity. In the rules editor, you would reference the velocity in a WHEN clause of a rule. For example:  

RETURN Review(“High number of purchases”) WHEN numPurchases > 5  

Test and Activate the Rule: Before activating the rule, test it to ensure it works as expected. Once you’re satisfied, activate the rule for it to take effect on real-time transaction assessments.  

  
For more detailed instructions, you can refer to the official documentation on Perform velocity checks – Dynamics 365 Fraud Protection | Microsoft Learn.  
 
 
 
9. How do I create an IP-based rule?  
Creating an IP-based rule in Microsoft Dynamics 365 Fraud Protection involves using the IP address as a condition within the rule’s logic. Here’s a general guide on how to create an IP-based rule:  

Access the Rules Editor: Navigate to the Dynamics 365 Fraud Protection portal and open the rules editor.  

Define the Rule: Use the RETURN and WHEN keywords to define your rule. The basic structure of a rule is as follows:  

RETURN <decision> WHEN <condition>  
  
For an IP-based rule, your condition will involve the IP address attribute. For example:  
RETURN Reject(“Suspicious IP”) WHEN @”device.ipAddress” == “192.168.1.1”  
  
Replace “192.168.1.1” with the actual IP address you want to monitor.  

Test the Rule: Before activating the rule, test it to ensure it correctly identifies transactions based on the IP address without impacting legitimate transactions.  

Activate the Rule: Once you’re satisfied with the rule’s performance, activate it to start using it for real-time transaction assessments.  

  
For more detailed instructions, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.  
 
 
 
10. Can you recommend the rule structure for MFA flow?  
In Microsoft Dynamics 365 Fraud Protection, setting up a rule structure for Multi-Factor Authentication (MFA) flow would typically involve creating rules that trigger MFA challenges based on certain conditions. Here’s a recommended structure for such a rule:  

Define the Condition: Identify the conditions under which you want to trigger MFA. This could be based on risk scores, user behavior, transaction details, or other attributes.  

Create the Rule: Use the RETURN and WHEN keywords to define your rule. The basic structure of a rule is:  

RETURN <decision> WHEN <condition>    
For example, if you want to challenge a login attempt when the risk score is high, your rule might look like this:  
RETURN Challenge(“MFA Required”) WHEN @”riskscore” > 800    

Test the Rule: Before activating the rule, test it to ensure it correctly identifies scenarios for MFA without impacting legitimate users.  

Activate the Rule: Once you’re satisfied with the rule’s performance, activate it to start using it for real-time assessments.  

  
For more detailed instructions, you can refer to the official documentation on Manage rules – Dynamics 365 Fraud Protection | Microsoft Learn.  
   Read More

​

In the realm of software development, code signing certificates play a pivotal role in ensuring the authenticity and integrity of code. For individual developers, obtaining these certificates involves a rigorous identity validation process. This blog explores the challenges individual developers face and how Trusted Signing can streamline the code signing process, with a focus on how its individual validation process contributes to this efficiency. 

Challenges faced by Individual Developers in Code Signing 

Individual developers often face unique challenges when it comes to code signing. Here are some key issues: 

Identity Validation process: This includes challenges such as obtaining the necessary documentation, undergoing lengthy verification processes, and dealing with differing requirements from various CAs.  

Private Key Theft or Misuse: Private keys are crucial for the code signing process and must be protected at all times. If these keys are stolen, attackers can use the compromised certificates to sign malware, distributing harmful software under a verified publisher name. It is expensive for individual developers to invest in the infrastructure and operations required to manage and store the keys. 

Complexity and Cost: The process of obtaining and managing code signing certificates can be complex and expensive, especially for individual developers and small teams. This complexity can lead to incomplete signing or not signing at all. 

Integration with DevOps: Code signing needs to be integrated with DevOps processes, tool chains, and automation workflows. Ensuring that access to private keys is easy, seamless, and secure is a significant challenge. 

Code Integrity and Security: While code signing ensures the integrity of software, it does not guarantee that the signed code is free from vulnerabilities. Hackers can exploit unregulated access to code signing systems to get malicious code signed and distributed. 

What is the Trusted Signing service?  

Trusted Signing is a comprehensive code signing service supported by a Microsoft-managed certification authority. The identity validation process is designed to be robust. Certificates are issued from Microsoft-managed CAs and are subsequently protected and serviced by providing seamless integration with leading developer toolsets. This eliminates the need for individual developers to invest in additional infrastructure and operations. 

The Importance of Identity Validation 

Identity validation is crucial for securing code signing certificates. It ensures that the individual requesting the certificate is indeed who they claim to be, thereby preventing malicious actors from distributing harmful code under the guise of legitimate software. This process builds trust among users and stakeholders, as they can be confident that the signed code is authentic and has not been tampered with. 

Process for Identity Validation with Trusted Signing 

Trusted Signing utilizes Microsoft Entra Verified ID (VID) for identity validation of individual developers. This process ensures that developers receive a VID, which is accessible through the Authenticator app, offering enhanced security, a streamlined process, and seamless integration with Microsoft Entra.  

The verification process involves the following steps:  

Submission of Government-Issued Photo ID: The first requirement is to provide a legible copy of a currently valid government-issued photo ID. This document must include the same name and address as on the certificate order. 
Biometric/selfie check: Along with the photo ID, applicants need to submit a selfie. This step ensures that the person in the ID matches the individual applying for the certificate. 
Additional Verification Steps: If the address is missing on the government issued ID card, then additional documents will be required to verify the address of the applicant. 

This is how a successfully procured VID would appear in Azure portal. 

Best Practices for a Smooth Validation Process 

To ensure a smooth and successful identity validation process, individual developers should adhere to the following best practices: 

Accurate Documentation: Ensure that all submitted documents are accurate and up-to-date and follow the guidelines. 

Stay Informed: Keep abreast of any changes in the validation requirements or processes of the CA you are working with. 

Costs of using Trusted Signing service 

Trusted Signing offers two pricing tiers starting at $9.99/month and you can pick the tiers based on your usage. Both tiers are designed to provide optimal cost efficiency and cater to various signing needs. You can find the pricing details here. The costs for identity validation, certificate lifecycle management, storing the keys securely, and signing are all included in a single SKU, ensuring accessibility and predictable expenses. 

Conclusion 

Identity validation is a critical step for individual developers seeking code signing certificates. By understanding the process, preparing in advance, and following best practices, developers can successfully navigate the validation process and secure their code signing certificates with Trusted Signing. This not only enhances the security of their software but also builds trust with users and stakeholders.

​Microsoft Tech Community – Latest Blogs –Read More 

Permissions of inactive identities in your Azure subscription should be revoked

It seems to be quite a long interval. Is there any way to accelerate it?

​Permissions of inactive identities in your Azure subscription should be revoked
 
It seems to be quite a long interval. Is there any way to accelerate it?  Read More

​

I am trying to allow end users to have a file upload option in their chat so that they can upload and interact with a file in the chat (I am not trying to ground the app on a specific dataset).   This option is available in the Chat Playground, but it seems to disappear when the app is deployed as a web app.   Is there something that I am missing?    I could swear that this used to be available for deployed web apps, but maybe I am wrong.  

​I am trying to allow end users to have a file upload option in their chat so that they can upload and interact with a file in the chat (I am not trying to ground the app on a specific dataset).   This option is available in the Chat Playground, but it seems to disappear when the app is deployed as a web app.   Is there something that I am missing?    I could swear that this used to be available for deployed web apps, but maybe I am wrong.    Read More

​

Hello, I am trying to populate the grid with IDs and I don’t want to manually input all the cells. The cells require taking the Letters on the left i.e. ‘FA’ plus the letter on the top i.e. ‘A’ to make the cell FAA.

Any assistant is welcome.

​Hello, I am trying to populate the grid with IDs and I don’t want to manually input all the cells. The cells require taking the Letters on the left i.e. ‘FA’ plus the letter on the top i.e. ‘A’ to make the cell FAA.Any assistant is welcome.   Read More

​

Microsoft 365 Copilot is transforming work in large and small ways. You may already be using it to get a recap of meetings you weren’t able to join, or to analyze chats for key information. It’s definitely changed the way I work and helped me be more productive with less effort.

But Copilot can do a lot more, so, let’s talk about ways to add intelligence to calls in Microsoft Teams. This powerful functionality enhances the ways we communicate and collaborate. It helps you organize and iterate on ideas, catch colleagues up quickly, and offers smarter ways to capture and act on information during and after calls.

Copilot in Teams Phone

Having Copilot integrated into Teams Phone means that it works with both VOIP (calls with another Teams user) and PTSN (calls using your phone number in Teams.) So, whichever way you connect, you can use Copilot in the same way you might use it in a Teams meeting. But since the nature of an unscheduled phone call can be different, let me show you some different scenarios that demonstrate how you can enable smart calling with Copilot.

Tag-team customer engagement: share context and transfer a customer call

Let’s say you’re on a call with a customer who has a lot of questions. Copilot can help you stay focused and make sure you’re on top of what’s been discussed by generating a summary of the conversation so far.

But what if you can’t answer all of their questions, and need to transfer them to a colleague who can? Copilot can help once again! To make sure your colleague is up to speed, before you do a consultative transfer, you can ask Copilot to create a list of unresolved questions.

Then you can send it, along with the conversation summary, when you transfer the call.

Those were some good examples of things you can do with Copilot while you’re on a call, but what about after it? In this second scenario, we’ll take a look at some ways it can help you days, weeks, …or any time after a call.

Recall support: retrieve information from a past call

This time, let’s imagine that you had a call with a colleague a few days ago. You remember that you reviewed a sales presentation with them, and that they had some feedback. But you can’t remember exactly what their feedback was. No worries, Copilot can help.

Ask Copilot to summarize the feedback from the call
In the chat box, you can use natural language to ask Copilot to remind you of the feedback your colleague shared. In just a few seconds, Copilot will generate a complete list of the feedback, with citations that link to the exact text in the transcript, so there’s no need to take the time to review the entire recording.

Project planning assistance: detail tracking and follow-up

When you’re planning a project, there are always tons of details to keep track of, and action items for everyone on the team to follow up on. Copilot can help you simplify and organize plans, and generate a list of action items based on what’s been discussed on a call.

Create a table to keep track of action items and deadlines

For example, if you’ve had a conversation with a colleague in Teams Phone about an upcoming event, you can ask Copilot to create a table that shows each item, who’s responsible for completing it, and the deadline. Copilot will review the transcript of your conversation, pull out all the necessary information, and lay it out clearly in a table.

Unlimited ideas: Brainstorming with Copilot

Next time you’re brainstorming with your colleagues on a call, ask Copilot to help you come up with new ideas. Copilot will consider all of the information you discussed as well as general information about the topic, and generate a bullet point list of workstreams and additional tasks that may need to be completed.

Take event planning as an example. To help you make your event a success, Copilot can come up with several new ideas of workstreams to consider.

Additional prompts to try with Copilot in Teams Phone

In addition to the examples above, you can use Copilot with Teams Phone in many of the same ways that you might use it with Teams Meetings.

Some additional prompts you can try are:

During the call:

“Copilot, can you help us brainstorm some ideas for our next steps on this project?
“Copilot, can you provide a quick summary of the challenges we’ve identified?”
“Copilot, can you list the potential solutions we’ve discussed for the issues raised?”

After the call:

“Create a workback schedule based on the deadlines we discussed”
“Summarize the feedback shared on [enter specific topic discussed]”
“Organize the decisions made and open items from the call in a table”

Don’t hesitate to try some of your own as well— start prompting like a pro today and see the difference in your productivity. The more you prompt and see Copilot’s responses, the better you’ll get at thinking of ways to get its help with more of your tasks.

Share your favorite prompts in the comments, we’d love to see what you come up with!

For additional information about using Copilot with Teams Phone, see the instructions in the Copilot Lab: Get started with Copilot in Microsoft Teams Phone.

Look for more tips to make the most of Copilot with Microsoft Teams coming soon.

​Microsoft Tech Community – Latest Blogs –Read More 

Intro

From the beginning of the cloud computing era, virtualization technology has enabled compute workloads to run as virtual machines (VMs) in a server environment. As hardware has become more sophisticated, and new functionality has become available, the software stack has kept VMs running seamlessly, thanks to sophisticated advances in the hypervisor and virtualization software.

Confidential computing is now a powerful technology for significantly improving the security of VMs running in the cloud. However, the trust boundary of a confidential VM imposes a barrier that prevents the hypervisor from offering the rich virtualization services that VMs normally expect. Customers desiring the benefits of confidential VMs have been forced to update the operating systems of their VMs to newer versions, which must be continually revised as confidential VM technology maintains its path of rapid evolution.

Microsoft has embraced a different approach that offers much more flexibility to customers through the use of a “paravisor”. A paravisor executes within the confidential trust boundary and provides the virtualization and device services needed by a general-purpose operating system (OS), enabling existing VM workloads to execute securely without requiring continual service of the OS to take advantage of innovative advances in confidential computing technology. As confidential computing becomes available on more hardware platforms and evolves, the software stack can keep VMs running seamlessly thanks to the paravisor, in much the same way other advances in virtualization software enabled VMs to run seamlessly on ever evolving hardware.

Microsoft developed the first paravisor in the industry, and for years, we have been enhancing the paravisor offered to Azure customers. This effort now culminates in the release of a new, open source paravisor, called OpenHCL. We plan to develop OpenHCL in the open here: microsoft/openvmm: Home of OpenVMM and OpenHCL (github.com).

OpenHCL capabilities

A paravisor is essentially an execution environment that runs within the guest VM – at a higher privilege level than the guest OS – and provides various services to the guest. A paravisor can run in both confidential environments and non-confidential environments. When running in a confidential environment, these privilege levels must be enforced by the confidential computing hardware platform.

We use virtual secure mode (VSM) to run a paravisor on Microsoft’s virtualization stack. When running in a confidential context, our architecture allows VSM to be appropriately enforced in a hardware platform-agnostic manner.

Today, OpenHCL can run on both x86-64 and ARM64 platforms, and it has support for Intel TDX and AMD SEV-SNP confidential computing platforms. OpenHCL runs in the L1 VMM of a TDX confidential VM and in the VMPL0 of an SEV-SNP confidential VM. See the OpenHCL user guide for step-by-step instructions to use it. OpenHCL offers a rich set of powerful services to both confidential and non-confidential VMs alike:

Device emulation via standard device interfaces, essentially offering a set of emulated devices, such as vTPM and serial.
Device translation via standard device interfaces, such as NVMe to para-virtualized SCSI, allowing assignment of hardware devices directly to VMs (accelerated IO) without requiring guest OS changes – enabling VMs to take advantage of the performance of cutting-edge devices.
Diagnostics support, particularly useful to allow debugging confidential VMs where it is difficult to use traditional methods of debugging.
(To confidential VMs specifically) Support for guests that are not fully enlightened – such as Windows and older versions of Linux – to run on confidential computing platforms via standard architectural interfaces.

For confidential VMs, even though OpenHCL unlocks amazing value to guests that are not fully enlightened (by enabling them), in the future OpenHCL could also provide a lot of value to fully enlightened guests by providing them with any or all its other services as different scenarios require it.

OpenHCL is used in Azure in new Azure Boost SKUs, and it will be used in future Azure confidential VM SKUs. In the past month alone, over 1.5 Million VMs were running with OpenHCL in Azure[1].

OpenHCL architecture

OpenHCL is composed of several open-source components, the most important one being OpenVMM, the cross platform, virtual machine monitor (VMM) project written in Rust. This VMM runs several user mode processes to power OpenHCL. Running a VMM inside OpenHCL allows us to support guests with assigned devices and provide device translation support. Additionally, it allows us to share confidential and non-confidential architecture. We run the same VMM in the same environment for both confidential and non-confidential guests, and the VMM provides the same services tailored to their requirements. This avoids fragmented virtualization solutions among confidential and non-confidential VMs, moving towards closing the feature gaps of confidential VMs.

The other components of OpenHCL are a boot loader and a small, customized Linux kernel built to support the VMM, with min. Kconfig to minimize binary size and runtime RAM usage. Running a kernel to support our environment allows the VMM code to be mostly standard Rust, making it much more powerful by enabling the VMM to use the broadly supported and stable Rust toolchains and crate ecosystem.

The two approaches to running confidential VMs

There are two approaches to running a guest OS inside a confidential VM: either the guest must be fully enlightened (modified to understand and manage all aspects of running as a confidential VM), or it can rely on a paravisor to implement the confidential computing enlightenments on its behalf. When a guest runs in with a paravisor, it doesn’t seem like a confidential guest precisely because it doesn’t need to act like a confidential guest.

In Azure, we support all IaaS confidential VMs via a paravisor today. The paravisor enabled Azure to support the widest variety of guests, including Windows versions released almost a decade ago[2] and Linux versions using kernels as old as the 5.19 kernel[3] (and versions using even older kernels that had a small set of patches backported, such as some Ubuntu and RHEL distro versions).  This provided customers with an easier lift as well as the flexibility to gain future confidential computing advances without needing to upgrade their workloads. Customers’ legacy solutions are safe with Azure because of the approach we embraced.

Why is Windows not fully enlightened to run as a confidential guest? I.e., why does Windows rely on a paravisor?

When we developed the first confidential VM in Azure on the confidential computing hardware platforms available at the time, it was not possible to fully enlighten Windows guests for those platforms because Windows required APIC (interrupt controller) emulation to be done in a paravisor. APIC emulation, traditionally done by the hypervisor, must be done by another entity for confidential VMs, where the hypervisor is outside the trust boundary. It can be done by the paravisor or by the hardware platform if it supports APIC virtualization, which early platforms like 3rd Gen AMD EPYC™ processors, didn’t.

On those hardware platforms, APIC emulation had to be done in a paravisor for Windows guests but not necessarily for Linux guests. The architecture of Windows relies directly on the APIC for interrupt management. Some aspects of Windows interrupt management don’t flow through the kernel and are inlined in drivers, so Windows drivers rely on the interrupt management behavior offered by the APIC. The architecture of Linux, on the other hand, doesn’t rely directly on the APIC for interrupt management. Linux offers kernel service routines for handling interrupt state, so Linux drivers rely on these routines.

In addition to that, Windows relies on the presence of a TPM for security features, and one cannot implement a vTPM for a confidential VM with enlightenments alone. We chose to implement a vTPM in a paravisor. Given all the functionality we have built into the paravisor, our plan is not to fully enlighten Windows and continue supporting Windows guests via a paravisor in Azure. For future versions of Linux, we’re evaluating both approaches –fully enlightened and relying on a paravisor – and we will aim to do what is best for customers.

OpenHCL and COCONUT-SVSM

An SVSM like COCONUT-SVSM plays a very valuable role for confidential computing. It can store secrets and provide virtualization services to improve the usability of fully enlightened guests. OpenHCL solves a different problem than COCONUT-SVSM. COCONUT-SVSM aims to provide services to confidential VMs with fully enlightened guests using new interfaces. OpenHCL aims to provide services to confidential VMs using existing standard architectural interfaces.

COCONUT-SVSM provides device emulation, but OpenHCL uniquely provides this via existing standard interfaces. When running with an SVSM (like COCONUT-SVSM), the guest must establish a specific relationship with the SVSM by discovering its presence and then interact with the SVSM using a custom calling convention. Essentially, a guest needs to be specifically modified to be able to take advantage of SVSM services, including devices. With OpenHCL, devices are easier to consume because existing device interfaces just work, and the guest does not need any custom calling contract modifications to consume them. OpenHCL enables devices to be discovered over standard enumeration mechanisms, like PCI virtualization or existing vTPM device contracts.

COCONUT-SVSM could potentially be leveraged by OpenHCL in the future. The VMM of component OpenHCL is Rust based, which has strong memory safety properties, and evolving its kernel component to also be Rust based would improve the memory safety of OpenHCL. During the development of OpenHCL, we chose the Linux kernel because it was a familiar OS platform for contributors and provided the capabilities needed. Now that Rust-based COCONUT-SVSM exists, we are interested in moving to that in the future and building OpenHCL support for it if it gains the features that OpenHCL needs.

Open for collaboration

In this blog we described the value of OpenHCL for the future of computing. We still have much more we plan to do with OpenHCL, and as we develop new functionality in the open, we would love to collaborate with you. You can learn more about this project on: https://openvmm.dev. Please reach out to us if you have ideas you’d like to add to the OpenHCL roadmap or any other feedback. You can open a GitHub issue, reach out to us on Zulip, and even contribute to this project! We track the roadmap of OpenHCL in the open; below are some of its future milestones!

OpenHCL support for Intel TDX (Trust Domain Extensions)

Intel and Microsoft collaborated on and co-developed the TDX partitioning architecture so that it could be leveraged by a paravisor. The first ever TDX module with TD partitioning was an amazing co-engineering project between Intel and Microsoft, and Intel released TD partitioning as part of the TDX Module that accompanied the general availability of 5th Generation Xeon, and this has also been backported to 4th Generation Xeon. Using this TDX module, Azure launched the first generation of Azure TDX confidential VMs with the first paravisor, being the first cloud service provider to offer TDX in public preview as well as the first cloud service provider to offer Windows guest support for TDX. Intel has been contributing for the past 6+ months, and we’re close to feature completeness in OpenHCL for the next generation of Azure TDX confidential VMs!

OpenHCL support for Arm CCA (Confidential Compute Architecture)

We started engaging with Arm almost two years ago to make sure the Arm Confidential Compute Architecture (CCA) is well equipped to support paravisor stacks like OpenHCL. CCA comprises a collection of open-source software, firmware, specifications, and hardware support to bring confidential computing to the Arm architecture.  CCA provides protected environments called Realms, that can be used to host confidential VMs. Our collaboration lead to the creation of the Planes feature, which enables multiple of levels of privilege to coexist inside a Realm. Planes provide the ability to host a paravisor, and a guest VM in the same Realm, with the paravisor providing security and compatibility services to the guest. We are excited to collaborate further and in the open with Arm to build OpenHCL support for Arm CCA.

OpenHCL support for AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging)

We used AMD’s VMPLs to build the first paravisor for confidential VMs in Azure. We have been engaging with AMD to ensure OpenHCL and AMD’s platform can best work together to provide great performance and security for customers. We will continue developing OpenHCL support for future generations of Azure SNP confidential VMs.

OpenHCL support for KVM as host

Today OpenHCL runs only on the MSFT hypervisor. We are excited to begin developing OpenHCL support for KVM as host in collaboration with other cloud service providers and the Linux and KVM community to enable others to leverage OpenHCL in their virtualization stacks.

– the Core OS Platform team.

​Microsoft Tech Community – Latest Blogs –Read More 

The Windows update is not currently updating.

​The Windows update is not currently updating.  Read More

​