###BeginCaseStudy###
Case Study: 6
Lucerne Publishing
Scenario:
COMPANY OVERVIEW
Overview
Lucerne Publishing is a large publishing company that produces both traditional books and ebooks.
Physical Location
The company has a main office and a branch office. The main office is located in New York.
The branch office is located in San Francisco. The main office has a satellite office located in
Boston. The company has 7,500 users.
EXISTING ENVIRONMENT
Active Directory Environment
The network contains an Active Directory forest. The forest contains a single domain named
lucernepublishing.com.
Network Infrastructure
Client computers in the New York office and the San Francisco office run either Windows
Vista or Windows XP. All client computers in the Boston office run Windows 7.
The company has a finance department. All of the client computers in the finance department
run Windows XP. The finance department uses an Application named App1. App1 only runs
on Windows XP.
The relevant servers in the New York office are configured as shown in the following table.
The servers have the following configurations:
• Remote Desktop is enabled on all servers.
• The passwords for all service accounts are set to never expire.
• Server1 stores roaming user profiles for users in the Boston office.
• SQL1 and SQL2 are deployed in a two-node failover cluster named Clusterl.
• All servers have Pre-Boot Execution Environment (PXE)-compliant network
adapters.
• The servers in the San Francisco office contain neither a recovery partition nor optical
media drives. DFSl and DFS2 are members of the same DFS Replication group. The DFS
namespace is configured to use Windows 2000 Server mode.
The Boston office has no servers. The Boston office connects to the New York office by
using a dedicated hardware VPN device.
The finance department publishes monthly forecast reports that are stored in DFS.
REQUIREMENTS
Business Goals
Lucerne Publishing must minimize administrative costs, hardware costs, software costs, and
development costs, whenever possible.
Planned Changes
All client computers will be upgraded to Windows 7.
A VPN server will be deployed in the main office. All VPN clients must have the latest
Windows updates before they can access the internal network.
You plan to deploy a server that has the Remote Desktop Gateway (RD Gateway) role
service installed.
Technical Requirements
Lucerne Publishing must meet the following technical requirements:
• Upgrade all client computers to Windows 7.
• Minimize Group Policy-related replication traffic.
• Ensure that App1 can be used from client computers that run Windows 7.
• Ensure that users can use App1 when they are disconnected from the network.
• Ensure that you can perform a bare metal recovery of the servers in the San Francisco
office.
• Minimize the amount of time it takes users in the Boston office to log on to their
client computers.
• Ensure that domain administrators can connect remotely to all computers in the
domain through RD Gateway.
• Ensure that file server administrators can access DFS servers and file servers through
the RD Gateway.
• Prevent file server administrators from accessing other servers through the RD
Gateway
Security Requirements
Lucerne Publishing must meet the following security requirements:
• USB storage devices must not be used on any servers.
• The passwords for all user accounts must be changed every 60 days.
• Users must only be able to modify the financial forecast reports on DFSl. DFS2 must
contain a read-only copy of the financial forecast reports.
• All operating system drives on client computers that run Windows 7 must be
encrypted.
• Only approved USB storaqe devices must be used on client computers that run
Windows 7.
###EndCaseStudy###
You need to recommend changes to the infrastructure to ensure that DFS meets the company’s
security requirements. What should you include in the recommendation?
A.
Upgrade DFS2 to Windows Server 2008 R2.
B.
Implement accessbased enumeration (ABE).
C.
Implement Authentication Mechanism Assurance.
D.
Configure the DFS namespace to use Windows Server 2008 mode.
Explanation:
Users must only be able to modify the financial forecast reports on DFSl. DFS2 must contain a readonly copy of the financial forecast reports.
Both servers are part of the same replication group and it is in Windows 2000 server mode
http ://blogs.technet.com/b/filecab/archive/2009/04/01/configuring-a-read-only-replicatedfolder.aspx
Please read the following notes carefully before deploying the read-only replicated folders feature.
a) Feature applicability: The read-only replicated folders feature is available only on replication
member servers which are running Windows Server 2008 R2. In other words, it is not possible to
configure a replicated folder to be read-only on a member server running either Windows Server
2003 R2 or Windows Server 2008.
b) Backwards compatibility: Only the server hosting read-only replicated folders needs to be running
Windows Server 2008 R2. The member server that hosts a read-only replicated folder can replicate
with partners that are on Windows Server 2003 or Windows Server 2008. However, to configure and
administer a replication group that has a read-only replicated folder, you need to use the DFS
Management MMC snap-in on Windows Server 2008 R2.
c) Administration of read-only replicated folders: In order to configure a replicated folder as readonly replicated folder, you need to use the DFS Management MMC snap-in on Windows Server 2008
R2. Older versions of the snap-in (available on Windows Server 2003 R2 or Windows Server 2008)
cannot configure or manage a read-only replicated folder. In other words, these snap-ins will not
display the option to mark a replicated folder ‘read-only’.
d) Schema updates: If you have an older version of the schema (pre-Windows Server 2008), you will
need to update your Active Directory schema to include the DFS Replication schema extensions for
Windows Server 2008.
http ://blogs.technet.com/b/filecab/archive/2009/01/21/read-only-replicated-folders-on-windowsserver-2008-r2.aspx
Why deploy read-only replicated folders?
Consider the following scenario. Contoso Corporation has a replication infrastructure similar to that
depicted in the diagram below. Reports are published to the datacenter server and these need to be
distributed to Contoso’s branch offices. DFS Replication is configured to replicate a folder containing
these published reports between the datacenter server and branch office servers.
The DFS Replication service is a multi-master file replication engine – meaning that changes can be
made to replicated data on any of the servers taking part in replication. The service then ensures
that these changes are replicated out to all other members in that replication group and that
conflicts are resolved using ‘last-writerwins’ semantics.
Now, a Contoso employee working in a branch office accidentally deletes the ‘Specs’ sub-folder from
the replicated folder stored on that branch office’s file server. This accidental deletion is replicated
by the DFS Replication service, first to the datacenter server and then via that server to the other
branch offices. Soon, the ‘Specs’ folder gets deleted on all of the servers participating in replication.
Contoso’s file server administrator now needs to restore the folder from a previously taken backup
and ensure that the restored contents of the folder once again replicate to all branch office file
servers.
Administrators need to monitor their replication infrastructure very closely in order to prevent such
situations from arising or to recover lost data if needed. Strict ACLs are a way of preventing these
accidental modifications from happening, but managing ACLs across many branch office servers and
for large amounts of replicated data quickly degenerates into an administrative nightmare. In case of
accidental deletions, administrators need to scramble to recover data from backups (often up-todate backups are unavailable) and in the meantime, end-users face outages leading to loss of
productivity.
This situation can be prevented by configuring read-only replicated folders on branch office file
servers. A readonly replicated folder ensures that no local modifications can take place and the
replica is kept in sync with a read-write enabled copy by the DFS Replication service. Therefore,read-only replicated folders enable easyto-deploy and low-administrative-overhead data publication
solutions especially for branch office scenarios.
How does all this work?
For a read-only replicated folder, the DFS Replication service intercepts and inspects every file
system operation. This is done by virtue of a file system filter driver that layers above every
replicated folder that is configured to be read-only. Volumes that do not host read-only replicated
folders or volumes hosting only readwrite replicated folders are ignored by the filter driver.
Only modifications initiated by the service itself are allowed – these modifications are typically
caused by the service installing updates from its replication partners. This ensures that the read-only
replicated folder is maintained in sync with a read-write enabled replicated folder on another
replication partner (presumably located at the datacenter server).
All other modification attempts are blocked – this ensures that the contents of the read-only
replicated folder cannot be modified locally. As shown in the below figure, end-users are unable to
modify the contents of the replicated folder on servers where it has been configured to be readonly. The behavior is similar to that of a read-only SMB share – contents can be read and attributes
can be queried for all files, however, modifications are not possible.
