MB2-708 Dynamics CRM 2016 Deployment: Infrastructure, Security, and Maintenance

MB2-708 was a Microsoft Dynamics CRM 2016 installation and deployment exam. It retired on December 31, 2019, and belongs to the on-premises CRM era rather than today's cloud-first Dynamics 365 credential model. Its historical objective set still has technical value because it captures the infrastructure work required to deploy a multi-tier CRM application on Windows Server, SQL Server, IIS, Active Directory, and related services.

The exam rewarded administrators who could think beyond a single installer. A reliable deployment depended on prerequisites, identities, service accounts, database placement, web services, authentication, network access, reporting, client connectivity, backup, patching, and troubleshooting. Each choice affected security and supportability, so the deployment had to be treated as a system rather than a sequence of Next buttons.

Readers should keep that historical boundary clear. Modern Microsoft certifications increasingly assume cloud services and managed platforms, while MB2-708 represented a period when organizations commonly owned much more of the application stack. That contrast makes the exam useful for understanding why cloud CRM removed some operational burdens while leaving identity, data, integration, and governance concerns intact.

Deployment planning began with topology and supported prerequisites

A Dynamics CRM 2016 deployment could place web application roles, asynchronous services, sandbox processing, SQL Server databases, reporting components, and related services on different machines. The appropriate topology depended on scale, availability requirements, network design, security boundaries, and operational maturity. A small environment might consolidate roles, while a larger environment separated them for resilience or performance.

Prerequisite planning included supported Windows Server and SQL Server versions, domain membership, DNS, certificates, service accounts, storage, ports, and required software components. Administrators needed to verify those dependencies before installation because many apparent “CRM problems” were really infrastructure mismatches. A disciplined preflight checklist reduced rework and produced a deployment that could be reproduced in test, staging, and production.

Active Directory and service identities shaped the security boundary

Dynamics CRM relied heavily on Active Directory for users, groups, service identities, and authentication. Deployment administrators needed to understand which accounts ran application services, which permissions those accounts required, and how the application mapped domain identities to CRM users. Excess privilege increased risk, while insufficient privilege caused failures that were often difficult to diagnose after installation.

Service-account design also affected auditing and operations. Separate identities made it easier to identify which component was accessing SQL Server, performing asynchronous processing, or interacting with reporting services. Password lifecycle, delegation, SPNs, and account lockouts could all influence availability. The exam therefore treated identity as infrastructure, not merely as a user-administration task inside the CRM interface.

SQL Server and reporting services were central to application health

The organization database stored business records, metadata, security information, and configuration, making SQL Server design critical. Administrators had to think about database placement, collation, storage, backup, maintenance, and connectivity. Performance symptoms in the CRM interface could originate from database pressure, blocking, I/O constraints, or poorly maintained indexes rather than the web tier itself.

SQL Server Reporting Services provided another dependency for reporting scenarios. The deployment needed compatible reporting components, appropriate service permissions, and working communication between CRM and the report server. A complete administrator understood enough of both systems to isolate whether a failure belonged to CRM configuration, Windows authentication, SQL connectivity, or reporting infrastructure.

Claims-based authentication and IFD extended access beyond the internal network

Internet-facing deployment introduced a more complex authentication design. Claims-based authentication, Active Directory Federation Services, certificates, DNS records, and external publishing had to work together so users could authenticate securely without exposing internal services unnecessarily. Small certificate or name-resolution mistakes could make the entire deployment appear unavailable.

The technical lesson remains relevant even though product architecture has changed. External access requires a clear trust boundary, strong identity proof, protected transport, and careful publication of application endpoints. Historical MB2-708 candidates needed to understand how those pieces were implemented with the CRM 2016 stack; modern administrators solve the same class of problem with different managed services and identity platforms.

Client connectivity included browsers, Outlook, email, and mobile scenarios

A successful server installation was only part of the deployment. Users connected through supported browsers, the Dynamics CRM for Outlook client, mobile experiences, email integration, and other tools. Administrators had to plan versions, compatibility, URLs, authentication behavior, offline requirements, and how client-side changes would be distributed and supported.

Client troubleshooting required separating user-specific issues from environment-wide issues. One failed Outlook configuration might indicate credentials, local software, or profile state; widespread failures could point to certificates, DNS, server health, or authentication. This layered troubleshooting model remains useful because it prevents administrators from changing central infrastructure to solve a problem that exists only on one endpoint.

Maintenance required backups, updates, monitoring, and tested recovery

Production CRM systems changed constantly as users created data, solutions evolved, and Microsoft shipped updates. Administrators needed a maintenance model that protected organization databases, customizations, configuration, encryption material, and supporting services. A backup had little value unless the team understood restoration order and had tested recovery in an environment that resembled production.

Updates needed similar discipline. Compatibility, custom code, reporting, client components, and integrations could be affected by a rollup or platform change. A mature process tested updates, documented rollback options, monitored key services, and scheduled maintenance around business impact. The historical exam rewarded the same operational habits that still distinguish dependable application administration today.

Troubleshooting worked best when administrators followed component boundaries

CRM 2016 exposed symptoms through web errors, service failures, event logs, trace information, SQL errors, authentication messages, and client behavior. The fastest troubleshooting method was to identify which layer first became unhealthy, then gather evidence from that layer before making changes. Random configuration edits often obscured the original cause and introduced new variables.

Historical Dynamics CRM architecture and customer-process context helps explain why the platform had so many dependencies: it was a business application sitting on web, identity, database, and reporting infrastructure. The deployment administrator's job was to understand those boundaries well enough to move from symptom to responsible component instead of treating every error as a CRM application defect.

MB2-708 provides context for how CRM operations changed in the cloud era

Today, many server-level responsibilities that dominated MB2-708 are managed by Microsoft in cloud Dynamics 365. Customers no longer design every IIS role or maintain the underlying SQL instance for the service. However, they still own tenant governance, identity, data, integration, configuration, security roles, solution lifecycle, and operational readiness. The boundary moved; it did not eliminate administration.

Readers can pair this historical deployment page with modern Dynamics 365 orientation to see that evolution. The useful takeaway is not nostalgia for older infrastructure but a clearer understanding of which problems the cloud platform absorbed and which responsibilities remained with the organization implementing the business process.

The historical exam also expected administrators to understand organization creation and deployment administration after the initial server installation. Creating or importing an organization involved database operations, configuration data, security mappings, and validation that supporting services recognized the new tenant. In multi-organization environments, maintenance tasks had to account for each organization rather than assuming one database represented the entire CRM service.

Upgrade planning was equally infrastructure-heavy. A team moving from an older CRM version needed supported source versions, database backups, custom-solution assessment, test upgrades, client compatibility checks, and enough capacity to run conversion processes safely. An upgrade that completed technically could still be unsuccessful if customizations, reports, or integrations failed afterward. Historical deployment expertise therefore included application validation, not only setup execution.

MB2-708 also sat beside configuration and application exams. The related MB2-712 exam dealt with CRM customization and configuration, while MB2-713 focused on Sales. Those relationships matter because infrastructure administrators supported environments whose behavior was shaped by functional configuration and business usage. Troubleshooting often required cooperation across those boundaries.

Capacity planning is another lesson worth preserving. Web requests, asynchronous jobs, reporting workloads, database growth, search, integrations, and user concurrency did not place equal pressure on the same component. Administrators had to observe where bottlenecks appeared and scale the responsible tier rather than simply adding resources everywhere. That component-aware reasoning still applies to modern services even when Microsoft owns the underlying servers.

For modern readers, the strongest MB2-708 exercise is to compare responsibility matrices. List what the customer owned in an on-premises CRM 2016 deployment—operating systems, SQL, IIS, certificates, backups, patching, federation, capacity—and compare it with the responsibilities retained in cloud Dynamics 365. The difference makes the value of the service model concrete and prevents the mistaken idea that moving to SaaS eliminates operational governance altogether.

Disaster recovery planning went beyond taking database backups. Teams needed to know which configuration databases, organization databases, encryption material, certificates, DNS records, federation settings, custom components, and service-account dependencies were required to rebuild a functioning environment. A recovery runbook that omitted identity or certificate state could restore data yet still leave the application inaccessible. Testing the whole service was therefore more meaningful than proving a backup file existed.

Change documentation was equally important in an on-premises deployment. Firewall changes, service-account updates, SQL maintenance, certificate renewal, and application patches could all affect other components. Administrators who recorded what changed, when, why, and how to reverse it could troubleshoot much faster than teams relying on memory. MB2-708 is historical, but this operational discipline remains directly relevant to complex cloud-integrated systems.

Performance baselining completed the operational picture. Administrators needed to know what normal response time, job throughput, database growth, and service behavior looked like before they could recognize degradation. Monitoring without a baseline produces alerts without context. That lesson transfers directly to cloud administration: even when the provider operates the servers, customers still need meaningful application and user-experience baselines.