###BeginCaseStudy###
Topic 7, Contoso, Ltd Case D
Overview
Contoso, Ltd., is a manufacturing company that makes several different components that are used in
automobile production. Contoso has a main office in Detroit, a distribution center in Chicago, and
branch offices in Dallas, Atlanta, and San Diego.
The contoso.com forest and domain functional level are Windows Server 2008 R2. All servers run
Windows Server 2012 R2, and all client workstations run Windows 7 or Windows 8. Contoso uses
System Center 2012 Operations Manager and Audit Collection Services (ACS) to monitor the
environment. There is no certification authority (CA) in the environment.
Current Environment
The contoso.com domain contains the servers as shown in the following table:
Contoso sales staff travel within the United States and connect to a VPN by using mobile devices to
access the corporate network. Sales users authenticate to the VPN by using their Active Directory
usernames and passwords. The VPN solution also supports certification-based authentication.
Contoso uses an inventory system that requires manually counting products and entering that count
into a database. Contoso purchases new inventory software that supports wireless handheld scanners
and several wireless handheld scanners. The wireless handheld scanners run a third party operating
system that supports the Network Device Enrollment Service (NDES).
Business Requirements
Security
The wireless handheld scanners must use certification-based authentication to access the wireless
network.
Sales users who use mobile devices must use certification-based authentication to access the VPN.
When sales users leave the company, Contoso administrators must be able to disable their VPN access
by revoking their certificates.
Monitoring
All servers must be monitored by using System Center 2012 Operating Manager. In addition to
monitoring the Windows operating system, you must collect security logs from the CA servers by using
ACS, and monitor the services that run on the CA and Certificate Revocation List (CRL) servers, such as
certification authority and web services.
Technical Requirements
CA Hierarchy
Contoso requires a two-tier CA hierarchy. The CA hierarchy must include a stand-alone offline root and
two Active Directory-integrated issuing CAs: one for issuing certificates to domain-joined devices, and
one for issuing certificates to non-domain-joined devices by using the NDES. CRLs must be published to
two web servers: one in Detroit and one in Chicago.
Contoso has servers that run Windows Server 2012 R2 to use for the CA hierarchy. The servers are
described in the following table:
The IT security department must have the necessary permissions to manage the CA and CRL servers. A
domain group named Corp-IT Security must be used for this purpose. The IT security department users
are not domain admins.
Fault Tolerance
The servers that host the CRL must be part of a Windows Network Load Balancing (NLB) cluster. The CRL
must be available to users in all locations by using the hostname crl.contoso.com, even if one of the
underlying web servers is offline.
###EndCaseStudy###
Your network contains an Active Directory domain named contoso.com. The domain contains four
servers on a test network. The servers are configured as shown in the following table.
Server1 uses the storage shown in the following table.
You perform the following tasks:
On Server2, you create an advanced SMB share named Share2A and an applications SMB share
named Share2B.
On Server3, you create an advanced SMB share named Share3.
On Server4, you create an applications SMB share named Share4.
You add Server3 and Server4 to a new failover cluster named Clus1.
On Clus1, you configure the File Server for general use role, you create a quick SMB share
named Share5A, and then you create an applications SMB share named Share5B.
You plan to create a failover cluster of two virtual machines hosted on Server1. The clustered virtual
machines will use shared .vhdx files.
You need to recommend a location to store the shared .vhdx files.
Where should you recommend placing the virtual hard disk (VHD)?
A.
\\\\Clus1\\Share5A
B.
\\\\Server2\\Share2A
C.
\\\\Server4\\Share4D. the D drive on Server1
Explanation:
Cluster1 is configured as a file share for general use and quick smb share. You can’t place shared vhdx
disks on quick smb, and it’s not recommended to store Hyper-V stuff on general use file shares.
i think the answer is C. \\server4\share4
“… SMB Share – Applications: This profile creates an SMB file share with settings appropriate for Hyper-V, certain databases, and other server applications.”
http://www.techrepublic.com/blog/data-center/how-to-share-a-folder-in-windows-server-2012/
A few variations of answers for this question exist. But the correct answer seems to be always an Application Share, unless it’s on a File Server for general use.
Can we please have 70-414 v.3 fixed? Almost all of the pictures do not show up…
SMB Share – Applications This profile creates an SMB file share with settings appropriate for Hyper-V, certain databases, and other server applications.
There’s what seems to be the same question (and showing the servers and storage) but with different options for answers at http://www.aiotestking.com/microsoft/where-should-you-recommend-placing-the-virtual-hard-disk-vhd/. There people have rightly commented that shared vhdx requires either a csv on block storage or a scale out file server with file-based storage. So that seems to rule out all the other servers.
My guess would be that the shared vhdx could go on the (scsi) D drive on Server1, the Hyper-V server where the VMs for the virtual failover cluster will be. There may be better ways but you could build a single virtual scale-out file server on the same host and give it virtual hard disks to share. I think you could also set up another VM as an iSCSI target, with the initiators on the new virtual cluster servers, and add a drive on the target as a csv to the cluster. Would either of those work, or anyone got a better idea?
CSVs and scale-out file servers are still confusing me no matter how much I read. It’s amazing how hard Microsoft have found it to share a disk/volume between hosts. It’s the biggest weakness Hyper-V has compared to VMware which has its own file system VMFS which locks at the file level (ie the VM level) and multiple hosts have always been able to access, it all just works. Works fine with file shares too. You just don’t have to think about all this stuff.