For the Microsoft Dynamics CRM 2015 release, a new guide, Unified Service Desk Developer Guide, was created and all the topics related to learning and configuring Unified Service Desk were moved from the existing Unified Service Desk Administration Guide to this new guide. This is detailed in the Release history topic of the USD Admin Guide for the December 2014 release: https://technet.microsoft.com/en-us/library/dn798672.aspx.

This was done to ensure that administrator/customizers as well as developers can refer to a single guide to configure and extend Unified Service Desk instead of having to navigate around multiple documents.

As the new USD Developer Guide was published in the first week of December, 2014, it will take a while to be indexed and picked up by the search engines, and therefore be available in search results. However, the topics in the USD administration and developer guides have been cross-linked as required to ensure that the users can locate and find the related information.

The Learn to use Unified Service Desk, Configure Unified Service Desk, and the Unified Service Desk Walkthroughs sections have been moved under the Configure your agent application section in the new USD Developer Guide.

Some of their (DQS and MDS) functionality can overlap because they are designed to work together and they are each designed to work without one another.

Both DQS and MDS play important roles in enterprise information management (EIM) scenarios.

• DQS emphasizes the cleansing, correction, and standardization of data through the collection of business knowledge in a DQS knowledge base, and the application of that knowledge in interactive and automated cleansing scenarios.
• MDS emphasizes the ongoing "care and feeding" of master data, providing a set of tools that allow business users to keep records up to date, while allowing IT departments to secure and manage the master data models, while integrating with external systems that utilize the master data.

Import and export

Both DQS and MDS have multiple ways to import and export data. They both work with SQL Server and Excel, but they do so in different ways.

DQS can import and export data to and from Excel and SQL Server:

• You can cleanse data from SQL Server or Excel source data files.
• You can export cleansed data into a SQL Server, CSV, or Excel file.
• You can import domains or values into a domain of a knowledge base by using an Excel file.
• You can import or export a knowledge base or domain by using a .dqs file.
• You can import values from a cleansing project (such as is created when the DQS Cleansing transformation is run) back into the knowledge base used by the project.

For MDS, you have several choices for importing and exporting data to and from MDS:

• You can load master data from an entity into Excel, and you can publish data into a model from Excel, by using the Master Data Services Add-in for Excel.
• You can also import data from SQL Server staging tables by using entity-based staging.
• You can export master data from MDS into a subscription view.

Whether to use Excel or SQL Server to import or export master data is likely to depend on who is performing the tasks, the size of the data, and whether the tasks are part of an automated process.

• Information workers are likely to find the Master Data Services Add-in for Excel useful because they are probably familiar with the product and used to performing manual tasks using it. IT pros are likely to find SQL Server processes useful given their skill sets.
• If you have a very large set of data, you are likely to want to use SQL Server processes rather than Excel. At a certain point, a large set of data becomes unmanageable in Excel.
• Entity-based staging and subscription views are easy to automate using SQL Server Integration Services and Transact-SQL. If you need to bulk-load data into an entity, use entity-based staging. Subscription views are used as a source for lookups because any data that goes into the MDM automatically shows up in a subscription view.

DQS Domain Rules and MDS Business Rules

Domain rules in DQS and business rules in MDS are both used to maintain the integrity of data, but they are used in different circumstances, as part of different operations, and from within different tools. Domain rules are used to identify data problems as part of a cleansing project, while business rules are used to prevent bad data from being introduced into MDS. The two types of rules can apply to the same data at different places in the information management lifecycle, so the same rule can end up being defined in both places.

DQS Domain Rules

A domain rule is used in the cleansing processes performed in DQS to identify problematic records. Domain rules are established in the domain management performed in the Data Quality client, and they are included in the applicable knowledge base. A domain rule enables you to specify conditions for the data that you are cleansing. You can add rules to specify values that are not allowed, and what the available values are or what the range of values is. Each record you cleanse is validated against the rules that apply to the domains in the record. If a check of a value fails, the value is marked as invalid.

MDS Business Rules

A business rule is used in Master Data Services to prevent the entry of problematic records. Business rules are created within the Master Data Manager Explorer, and they are part of the master data model. A business rule prevents the improper entry or modification of records. It is not about identifying master data within an entity that is already incorrect. It's about keeping bad data from being added to the MDM or introduced within the MDM. Master Data Services will prevent you from entering a new record or modifying an existing value if doing so would violate a business rule. Multiple processes trigger this validation of master data. Whenever you add or change data into the MDM, whether it's through the Excel Add-in, entity-based staging, the Web UI, or the API, applicable business rules are run on the records that are added or changed. If you are manually making changes in the MDM, you can use a business rule to validate the changes.

Read more about:

Data Quality Services

Master Data Services

If you have or know of a high-quality content (blogs, trainings, videos, articles) related to DQS that you want to share with the larger DQS community, please go ahead and add a link to the article on the TechNet Wiki page I mentioned earlier. Updating the article on TechNet Wiki is easy. You will need to sign in with your Microsoft account by clicking Sign In on the top-right corner of the page, and then click Edit on top of the article. Else, if you want my help to add the link to a community resource, please feel free to contact me with the required details.

Lets build an exhaustive resource of great community content for DQS!

The unit of failover in an Availability Group is a group of user databases only. However, just failing over 3 DQS databases is not sufficient for the DQS application to be highly available. The Data Quality Server component in DQS requires other objects apart from the 3 DQS databases to be functional such as SQL Common Language Runtime (SQLCR) assemblies, the 2 DQS SQL Server logins, and the DQS initialization stored procedure in the master database on the target SQL Server instance.

You must perform some additional steps when configuring AlwaysOn Availability Groups for DQS to make it highly available. This white paper describes how you can work around the above issues to build a HADR solution for DQS.

Hope you find it useful.

Thanks,
Vivek
(SQL Server Documentation | Twitter: @vivek_msft)

• Realty Trac
• Areva
• Vienna International Airport
• Heraeus Holding
• Vizio
• New Zealand Ministry of Health
• China Guangdong Nuclear Power Holding Corporation
• Yonyou Software Co. Ltd.
• Super 8 Hotels Co. Ltd.
• Rackspace Hosting
• Wipro Technologies
• Great Western Bank

Are there more DQS case studies in the pipeline?

Yes, there will be more DQS case studies published in future, and you can find the updated/latest set of DQS case studies on the DQS Learn page at https://technet.microsoft.com/en-us/sqlserver/hh780961.aspx. On this page, go to the Resources section, and then click the Case Studies tab to view all the DQS case studies.

See Also:

SQL Server Case Studies

Well, now you can do so; introducing database-level firewall rules in Windows Azure SQL Database! In addition to the server-level firewall rules, you can now define firewall rules for each database in your SQL Database server to restrict access to selective clients. To do so, you must create a database-level firewall rule for the required database with an IP address range that is beyond the IP address range specified in the server-level firewall rule, and ensure that the IP address of the client falls in the range specified in the database-level firewall rule.

This is how the connection attempt from a client passes through the firewall rules in Windows Azure SQL Database:

• If the IP address of the request is within one of the ranges specified in the server-level firewall rules, the connection is granted to your SQL Database server.
• If the IP address of the request is not within one of the ranges specified in the server-level firewall rule, the database-level firewall rules are checked. If the IP address of the request is within one of the ranges specified in the database-level firewall rules, the connection is granted only to the database that has a matching database-level rule.
• If the IP address of the request is not within the ranges specified in any of the server-level or database-level firewall rules, the connection request fails.

For detailed information, see Windows Azure SQL Database Firewall.

UPDATE as on April 8, 2015: The online SQL Server documentation now has a dedicated topic on how you can install and manage Books Online (BOL). See here for the most up-to-date information: https://msdn.microsoft.com/en-us/library/ms166020(v=sql.120).aspx.

----------------------------------------------------------------------------

If you are wondering why you don't have a local copy of Books Online for SQL Server 2012, here is the deal. Starting with SQL Server 2012, Microsoft has moved on to a new help technology where only the Help Viewer and related components are installed by the Microsoft SQL Server 2012 setup, which is used for viewing help and managing the help settings; no documentation is installed locally. All of the SQL Server documentation is available online, and you can download the documentation by using the Help Library Manager. But what if the computer you are installing SQL Server on is behind a firewall or proxy and has no access to the Internet.

Well, in that case you can directly download the Books Online for SQL Server 2012 from https://www.microsoft.com/download/en/details.aspx?id=347 to a computer that has Internet connection, and then use the Help Library Manager on the SQL Server computer to install the product doumentation locally. The Books Online download link mentioned earlier has instructions on how to do so.