az network dns zone create -g MyAzureResourceGroup \ -n chirkut.local \ –zone-type Private \ –registration-vnets myAzureVNet
List DNS zones
az network dns zone list \ –resource-group MyAzureResourceGroup
az network dns zone list
Create an additional DNS record
The following example creates a record with the relative name db in the DNS Zone chirkut.local, in resource group MyAzureResourceGroup. The fully qualified name of the record set is db.chirkut.local. The record type is “A”, with IP address “10.2.0.4”.
az network dns record-set a add-record \ -g MyAzureResourceGroup \ -z chirkut.local \ -n db \ -a 10.2.0.4
View DNS records
To list the DNS records in your zone, run:
az network dns record-set list \ -g MyAzureResourceGroup \ -z chirkut.local
Delete all resources
When no longer needed, delete the MyAzureResourceGroup resource group to delete the resources created in this tutorial.
The easiest, most common way to get started with DLP policies is to use one of the templates included in Office 365. You can use one of these templates as is, or customize the rules to meet your organization’s specific compliance requirements.
Office 365 includes over 40 ready-to-use templates that can help you meet a wide range of common regulatory and business policy needs. For example, there are DLP policy templates for:
Gramm-Leach-Bliley Act (GLBA)
Payment Card Industry Data Security Standard (PCI-DSS)
United States Personally Identifiable Information (U.S. PII)
United States Health Insurance Act (HIPAA)
You can fine tune a template by modifying any of the existing rules or adding new ones. For example, you can add new types of sensitive information to a rule, modify the counts in a rule to make it harder or easier to trigger, allow people to override the actions in a rule by providing a business justification, or change who notifications and incident reports are sent to. A DLP policy template is a flexible starting point for many common compliance scenarios.
You can also choose the Custom template, which has no default rules, and configure your DLP policy from scratch, to meet the specific compliance requirements for your organization.
Example: Identify sensitive information across all OneDrive for Business sites and restrict access for people outside your organization
OneDrive for Business accounts make it easy for people across your organization to collaborate and share documents. But a common concern for compliance officers is that sensitive information stored in OneDrive for Business accounts may be inadvertently shared with people outside your organization. A DLP policy can help mitigate this risk.
In this example, you’ll create a DLP policy that identifies U.S. PII data, which includes Individual Taxpayer Identification Numbers (ITIN), Social Security Numbers, and U.S. passport numbers. You’ll get started by using a template, and then you’ll modify the template to meet your organization’s compliance requirements—specifically, you’ll:
Add a couple of types of sensitive information—U.S. bank account numbers and U.S. driver’s license numbers—so that the DLP policy protects even more of your sensitive data.
Make the policy more sensitive, so that a single occurrence of sensitive information is enough to restrict access for external users.
Allow users to override the actions by providing a business justification or reporting a false positive. This way, your DLP policy won’t prevent people in your organization from getting their work done, provided they have a valid business reason for sharing the sensitive information.
Create a DLP policy from a template
Go to https://protection.office.com.
Sign in to Office 365 using your work or school account. You’re now in the Office 365 Security & Compliance Center.
In the Security & Compliance Center > left navigation > Data loss prevention > Policy > + Create a policy.
Choose the DLP policy template that protects the types of sensitive information that you need > Next.In this example, you’ll select Privacy > U.S. Personally Identifiable Information (PII) Data because it already includes most of the types of sensitive information that you want to protect—you’ll add a couple later.When you select a template, you can read the description on the right to learn what types of sensitive information the template protects.
Name the policy > Next.
To choose the locations that you want the DLP policy to protect, do one of the following:
Choose All locations in Office 365 > Next.
Choose Let me choose specific locations > Next. For this example, choose this.To include or exclude an entire location such as all Exchange email or all OneDrive accounts, switch the Status of that location on or off.To include only specific SharePoint sites or OneDrive for Business accounts, switch the Status to on, and then click the links under Include to choose specific sites or accounts. When you apply a policy to a site, the rules configured in that policy are automatically applied to all subsites of that site.
In this example, to protect sensitive information stored in all OneDrive for Business accounts, turn off the Status for both Exchange email and SharePoint sites, and leave the Status on for OneDrive accounts.
Choose Use advanced settings > Next.
A DLP policy template contains predefined rules with conditions and actions that detect and act upon specific types of sensitive information. You can edit, delete, or turn off any of the existing rules, or add new ones. When done, click Next. In this example, the U.S. PII Data template includes two predefined rules:
Low volume of content detected U.S. PII This rule looks for files containing between 1 and 10 occurrences of each of three types of sensitive information (ITIN, SSN, and U.S. passport numbers), where the files are shared with people outside the organization. If found, the rule sends an email notification to the primary site collection administrator, document owner, and person who last modified the document.
High volume of content detected U.S. PII This rule looks for files containing 10 or more occurrences of each of the same three sensitive information types, where the files are shared with people outside the organization. If found, this action also sends an email notification, plus it restricts access to the file. For content in a OneDrive for Business account, this means that permissions for the document are restricted for everyone except the primary site collection administrator, document owner, and person who last modified the document.
To meet your organization’s specific requirements, you may want to make the rules easier to trigger, so that a single occurrence of sensitive information is enough to block access for external users. After looking at these rules, you understand that you don’t need low and high count rules—you need only a single rule that blocks access if any occurrence of sensitive information is found.
So you expand the rule named Low volume of content detected U.S. PII > Delete rule.
Now, in this example, you need to add two sensitive information types (U.S. bank account numbers and U.S. driver’s license numbers), allow people to override a rule, and change the count to any occurrence. You can do all of this by editing one rule, so select High volume of content detected U.S. PII > Edit rule.
To add a sensitive information type, in the Conditions section > Add or change types. Then, under Add or change types > choose Add > select U.S. Bank Account Number and U.S. Driver’s License Number > Add > Done.
To change the count (the number of instances of sensitive information required to trigger the rule), under Instance count > choose the min value for each type > enter 1. The minimum count cannot be empty. The maximum count can be empty; an empty max value convert to any.When finished, the min count for all of the sensitive information types should be 1 and the max count should be any. In other words, any occurrence of this type of sensitive information will satisfy this condition.
For the final customization, you don’t want your DLP policies to block people from doing their work when they have a valid business justification or encounter a false positive, so you want the user notification to include options to override the blocking action.In the User notifications section, you can see that email notifications and policy tips are turned on by default for this rule in the template.In the User overrides section, you can see that overrides for a business justification are turned on, but overrides to report false positives are not. Choose Override the rule automatically if they report it as a false positive.
At the top of the rule editor, change the name of this rule from the default High volume of content detected U.S. PII to Any content detected with U.S. PII because it’s now triggered by any occurrence of its sensitive information types.
At the bottom of the rule editor > Save.
Review the conditions and actions for this rule > Next.On the right, notice the Status switch for the rule. If you turn off an entire policy, all rules contained in the policy are also turned off. However, here you can turn off a specific rule without turning off the entire policy. This can be useful when you need to investigate a rule that is generating a large number of false positives.
On the next page, read and understand the following, and then choose whether to turn on the rule or test it out first > Next.Before you create your DLP policies, you should consider rolling them out gradually to assess their impact and test their effectiveness before you fully enforce them. For example, you don’t want a new DLP policy to unintentionally block access to thousands of documents that people require to get their work done.If you’re creating DLP policies with a large potential impact, we recommend following this sequence:
Start in test mode without Policy Tips and then use the DLP reports to assess the impact. You can use DLP reports to view the number, location, type, and severity of policy matches. Based on the results, you can fine tune the rules as needed. In test mode, DLP policies will not impact the productivity of people working in your organization.
Move to Test mode with notifications and Policy Tips so that you can begin to teach users about your compliance policies and prepare them for the rules that are going to be applied. At this stage, you can also ask users to report false positives so that you can further refine the rules.
Turn on the policies so that the rules are enforced and the content’s protected. Continue to monitor the DLP reports and any incident reports or notifications to make sure that the results are what you intend.
Review your settings for this policy > choose Create.
After you create and turn on a DLP policy, it’s deployed to any content sources that it includes, such as SharePoint Online sites or OneDrive for Business accounts, where the policy begins automatically enforcing its rules on that content.
View the status of a DLP policy
At any time, you can view the status of your DLP policies on the Policy page in the Data loss prevention section of the Security & Compliance Center. Here you can find important information, such as whether a policy was successfully enabled or disabled, or whether the policy is in test mode.
Here are the different statuses and what they mean.
The policy is being deployed to the content sources that it includes. The policy is not yet enforced on all sources.
Testing, with notifications
The policy is in test mode. The actions in a rule are not applied, but policy matches are collected and can be viewed by using the DLP reports. Notifications about policy matches are sent to the specified recipients.
Testing, without notifications
The policy is in test mode. The actions in a rule are not applied, but policy matches are collected and can be viewed by using the DLP reports. Notifications about policy matches are not sent to the specified recipients.
The policy is active and enforced. The policy was successfully deployed to all its content sources.
The policy is being removed from the content sources that it includes. The policy may still be active and enforced on some sources. Turning off a policy may take up to 45 minutes.
The policy is not active and not enforced. The settings for the policy (sources, keywords, duration, etc) are saved.
The policy is in the process of being deleted. The policy is not active and not enforced.
Turn off a DLP policy
You can edit or turn off a DLP policy at any time. Turning off a policy disables all of the rules in the policy.
To edit or turn off a DLP policy, on the Policy page > select the policy > Edit policy.
In addition, you can turn off each rule individually by editing the policy and then toggling off the Status of that rule, as described above.
Autodiscover is a feature which enables automatic client profile configuration and provides end point of Exchange Web Service (EWS) such that clients can utilize EWS related feature like getting free busy information. The following TechNet explains more about Autodiscover.
Let me explain some key words and detail behaviors.
What is SCP ?
SCP is abbreviation for Service Connection Point, which means connection end points for Exchange related service. SCP is created for each CAS (in Exchange 2007/2010) or Mailbox server. SCP can be found at Active Directory Configuration partition by using ADSI Editor as follows.
[Configuration] – [CN=Configuration,DC=example,DC=local] – [CN=Services] – [CN=Microsoft Exchange] – [CN=<Organization Name>] – [CN=Administrative Groups] – [CN=Exchange Administrative Group (FYDIBOHF23SPDLT)] – [CN=Servers] – [CN=<CAS or Mailbox server name>] – [CN=Protocols] – [CN=Autodiscover] – [CN=<CAS or Mailbox server name>]
Which SCP does Outlook client access?
We should be aware of which AD site clients belong to.
Outlook looks at Keyword attribute in SCP from the SCP list. This Keyword attribute contains AD site name and Outlook checks if its AD site matches with the one defined in the Keyword attribute. If Outlook finds SCP whose Keyword attribute matches with its AD site, Outlook sends Autodiscover request to URL defined in ServiceBindingInformation attribute of that SCP.
If there aren’t any SCP which has client’s AD site, Outlook attempts to connect each SCP in the order of the SCP list obtained by LDAP query. There is no sort mechanism in SCP list so in general Outlook connects to SCP in random order. (As a rule of thumb, it is the order by the time SCP was created).
In other words, autodiscover access point is configurable by changing Keyword or ServiceBindingInformation attributes. Those attributes can be defined by Set-CleintAcessServer command and Keyword attribute corresponds to AutodiscoverSiteScope parameter and ServiceBindingInformation attribute to AutodiscoverServiceInternalUri parameter.
There is TechNet article which explains how to control target SCP by utilizing AutodiscoverSiteScope parameter.
Configure the Autodiscover Service to Use Site Affinity
Non-domain joined or Workgroup clients cannot access SCP, so those clients start trying to connect from Step (2) explained above. It means we need DNS A record for autodiscover.<smtp-address-domain> or hosts file which has autodiscover.<smtp-address-domain> entry.
Resource/Account forest scenario
If you are running Exchange in resource/account forest topology, you have user accounts and clients reside in account forest and utilize “Linked mailbox” to connect to mailboxes which are in resource forest. In order for clients to successfully make autodiscover connection, you should either have SCPs in account forest or create DNS records (since SCP lookup fails).
There is an Exchange PowerShell command called Export-AutoDiscoverCnnfig to create SCP in account forest. You ran this command from Exchange in resource forest as follows.
Export-AutoDiscoverConfig -TargetForestDomainController <DC in account forest> -TargetForestCredential:(get-credential).
For more detail on Export-AutoDiscoverConfig, check up the following TechNet below.
SCP created in account forest has ServiceBindingInformation attribute pointing to LDAP URL of resource forest (Example: LDAP://example.com).
Outlook client attempts to connect DC in resource forest based on this LDAP URL and get ServiceBindingInformation attribute of SCP in resource forest.
How does Outlook client attempt to connect SCP if there are multiple SCPs in resource forest?
The behavior is the same as I explained previously. Outlook relies on Keyword attribute (AutodiscoverSiteScope). In other words, if SCP of CAS or Mailbox server set AutodiscoverSiteScope as AD site called “AccountForest01”, all clients in “AccountForest01” always attempt to connect AutodiscoverServiceInternalUri of the corresponding Exchange servers.
Hybrid Exchange scenario
If you are planning to migrate Onpremise Exchange to Exchange Online, you may need to configure Hybrid Exchange. I think the importance of Autodiscover is even greater in Hybrid Exchange scenario because Autodiscover helps user connect to mailbox in Exchange Online without any manual profile setting after migration. You may wonder how Outlook detect correct target Exchange server even if mailbox is moved from Onpremise Exchange to Exchange Online. The secret is remote mailbox in Onpremise Exchange. If you move mailbox to Exchange Online under Hybrid environment, moved mailbox turns into “Remote mailbox”, which is basically mail enabled user. This mailbox conversion process is a part of mailbox migration and is done automatically.
The process of finding Autodiscover end point does not rely on mailbox location (Onpremise or cloud) but is consistent as I explained earlier. Domain-joined client first looks up SCP and attempts to connect to Onpremise Exchange servers defined in SCP. If the mailbox is moved to Exchange Online or the mailbox becomes remote mailbox, Outlook client make another autodiscover request based on RemoteRoutingAddress parapeter of the remote mailbox.
Here is how Outlook attempts to make Autodiscover request.
3) Autodiscover to https://contoso.mail.onmicrosoft.com/autodiscover/autodiscover.xml
4) Autodiscover to https://autodiscover.contoso.mail.onmicrosoft.com/autodiscover/autodiscover.xml
5) Local autodiscover to contoso.mail.onmicrosoft.com
6) Redirect check to http://autodiscover.contoso.mail.onmicrosoft.com/autodiscover/autodiscover.xml
7) Autodiscover URL redirection to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
8) Autodiscover to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
9) Redirect check to http://autodiscover.contoso.mail.onmicrosoft.com/autodiscover/autodiscover.xml
If clients are domain-joined, Step1 is always performed and client attempts to connect to Onpremise Exchange servers.
If you enable AutoDiscover registry on Outlook Client, client skips looking up SCP even if it is domain-joined.
HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook version (Note)>\Outlook\AutoDiscover
Value Name: ExcludeScpLookup
Type : REG_DWORD
Value : 0x00000001 (1)
14.0 for Outlook 2010,15.0 for Outlook 2013 and 16.0 for Outlook 2016
So far, we covered a basic autodiscover behavior and how Outlook client makes autodiscover request under a few well-known scenarios.
Now I want to walk you through some troubleshooting steps so that you understand if autodiscover is working or what is going wrong.
Check with Test E-mail AUtoConfiguration
Test E-mail AutoConfiguration is your friend. Test E-mail AtoConfiguration helps you to check if Autodiscover succeeds or how far AUtodiscover process goes till it fails.
1) Start Outlook.
2) Logon to Outlook profile and then right click on Outlook icon in Task tray.
3) Click “Test E-mail AutoConfiguration”
4) Enter correct email address if needed and provide credential if asked.
5) Check only “Use Autodiscover”
6) Check “Results” tab if autodiscover succeeds and check “Log” tab to see where autodiscover fails.
Here is a sample.
If you are familiar with Autodiscover response (XML), checking “XML” tab helps you see if client receive expected response.
————– Additional tips —————–
You can utilize Test E-mail AutoConfiguration even if you don’t have any Outlook profile.
Here are the steps.
1) Delete all profiles and start OUtlook
2) Enter Outlook profile name and click “OK”.
3) Click “Cancel” and then “OK” for dailogue box not to create a profile.
4) Click “Next” for Profile creation wizard.
5) Click “No” and then click “Next”
6) Check “Use Outlook without an email account” and click “Finish”
Test with browser access
You can use any browser to access Autodiscover endpoint. If it fails, you may have network issue or other causes that prevent you from accessing it.
If Outlook client is non-domain joined,AutoDiscover endpoint is most likely https://autodisocver.<SMTP-address-domain>/autodiscover/autodiscover.xml.
Open up any browser and try accessing that endpoint.
You will be asked for credential and if you provide correct credential and see the following response below, you can successfully access the endpoint. If not, you should troubleshoot further (It is most likely network related troubleshooting)
This error can occur if the settings in “Network security: Minimum session security for NTLM SSP based (including secure RPC) clients” policy on the client computer are not the same as the settings in the “Network security: Minimum session security for NTLM SSP based (including secure RPC) servers” policy on this server. By default, the “Require 128-bit encryption” setting is disabled for computers running Windows Server 2008, Windows Vista, Windows Server 2003, Windows 2000 Server, or Windows XP. For computers running Windows 7 or Windows Server 2008 R2, this setting enabled by default. Resolution:
Ensure that the “Network security: Minimum session security for NTLM SSP based (including secure RPC) clients” policy settings on the computers from which users log on are the same as “Network security: Minimum session security for NTLM SSP based (including secure RPC) servers” policy settings on this server.
Microsoft Exchange Server 2016 brings a new set of technologies, features, and services to Exchange Server, the messaging platform that provides email, scheduling, and tools for custom collaboration and messaging service applications. Its goal is to support people and organizations as their work habits evolve from a communication focus to a collaboration focus. At the same time, Exchange 2016 helps lower the total cost of ownership whether you deploy Exchange 2016 on-premises or provision your mailboxes in the cloud.
The Mailbox server in Exchange 2016 includes all of the server components from the Exchange 2013 Mailbox and Client Access server roles:
1- Client Access services provide authentication, limited redirection, and proxy services. Client Access services don’t do any data rendering and offer all the usual client access protocols: HTTP, POP and IMAP, and SMTP.
2- Mailbox services include all the traditional server components found in the Exchange 2013 Mailbox server role: the backend client access protocols, Transport service, Mailbox databases, and Unified Messaging. The Mailbox server handles all activity for the active mailboxes on that server.
The Edge Transport role is typically deployed in your perimeter network, outside your internal Active Directory forest, and is designed to minimize the attack surface of your Exchange deployment. By handling all Internet-facing mail flow, it also adds additional layers of message protection and security against viruses and spam, and can apply mail flow rules (also known as transport rules) to control message flow.
Outlook on the web (formerly Outlook Web App) Outlook Web App is now known as Outlook on the web, which continues to let users access their Exchange mailbox from almost any web browser.
he former Outlook Web App user interface has been updated and optimized for tablets and smart phones, in addition to desktop and laptop computers.
MAPI over HTTP MAPI over HTTP is now the default protocol that Outlook uses to communicate with Exchange. MAPI over HTTP improves the reliability and stability of the Outlook and Exchange connections by moving the transport layer to the industry-standard HTTP model. This allows a higher level of visibility of transport errors and enhanced recoverability. Additional functionality includes support for an explicit pause-and-resume function, which enables supported clients to change networks or resume from hibernation while maintaining the same server context.
MAPI over HTTP isn’t enabled in organizations where the following conditions are both true:
– You’re installing Exchange 2016 in an organization that already has Exchange 2013 servers installed.
– MAPI over HTTP wasn’t enabled in Exchange 2013.