As you can see, branch offices were faced with numerous challenges. Because of the many features of RODCs, however, branch offices can now have domain controllers on site without compromising security.
The main benefits of running RODC in branch offices are associated with the following:
. Read-only Active Directory Domain Services
. Reduced replication workload over the network
. Credential caching
. Administrator role separation
. Read-Only DNS
. Read-Only SYSVOL
These features of RODCs, which are discussed in detail in the following sections, assist in alleviating concerns and dilemmas for organizations.
Read-Only Active Directory Domain Services
Poor physical security is typically the most common rationale for deploying an RODC at a branch office. A read-only copy of the domain controller provides fast and reliable authentication, while simultaneously protecting against data loss in the event the server is compromised or stolen. Because no changes can originate from an RODC, a malicious hacker or IT support personnel with little knowledge of Active Directory administration cannot make changes at the branch level. On a writable domain controller, not only can changes be made, but these changes would propagate to all other domain controllers, eventually damaging or polluting the Active Directory domain and forest.
Reduced Replication Workload over the Network
As mentioned earlier, RODCs do not participate in Active Directory replication in the same fashion as writable domain controllers. Replication with RODC is one-way, meaning all changes from a writable domain controller are propagated to the RODC. An RODC receives changes, but does not partake in or perform any outbound replication to other domain controllers. This results in the replication workload being minimized over the network because changes do not have to be pulled from an RODC and because Active Directory replication is unidirectional. Also reduced is the amount of time required to monitor replication, which is another plus for having an RODC.
Credential Caching
Credential caching with an RODC provides numerous security enhancements for a domain controller residing at a branch office. Take, for example, a new functionality in RODCs that increases security in the event an RODC is stolen. When replication transpires between a writable domain controller and an RODC, only a user’s account information is replicated—not the user’s password. Equally important, passwords are not stored on an RODC. In the event the RODC is stolen, the only accounts that can be hacked and compromised are the local administrator accounts and the RODC account, which is specific to the RODC server. These accounts are not considered to be highly privileged, nor do they have access authorization on the forest and domain. On the other hand, traditional writable domain controllers store both the user’s account information and password on a domain controller, ultimately leaving users very vulnerable.
Because an RODC by default does not store user accounts or passwords locally, branch office users must authenticate against a writable domain controller in a hub site. This is often not practical for branch office users, especially if the WAN link between the sites is slow or unavailable. In this case, it is possible to configure password replication caching for specific branch office users on the branch office RODC. After the credentials are cached on the RODC, the domain controller will service users the next time they try to log on and every other time after that until the credentials change. Typically, a branch office only has a few users, so only a subset of an organization’s users’ accounts are cached on the RODC at the branch office, limiting the exposure of credentials in the event of a system breach.
To provide an additional level of security and at the same time reduce the amount of information exposed in the event an RODC is stolen, a domain administrator can use tools within Active Directory Users and Computers to delete the RODC from the Active Directory domain/forest and reset the passwords for user accounts cached on the RODC.
Administrator Role Separation
Organizations are encouraged to use RODCs when there is a need to satisfy unique administrative requirements and to maintain administrator role separation and isolation. The use of an RODC is especially encouraged if the domain controller situated in a branch office hosts more than one server function or server role, such as a print server, messaging server, file server, and much more. The use of an RODC is also recommended when there are other applications installed on the domain controller. Traditionally, in this situation the administrator of these applications has privileges not only to the applications, but also to the entire Active Directory, which can pose a threat. With RODC, however, you can delegate permissions to local administrators, granting them rights to a particular server, roles, or LOB applications without ever granting them access to Active Directory or
domain resources beyond the scope of the branch. As a result, the local administrator at the branch can perform his or her administrator work activities effectively without compromising the entire Active Directory environment.
Read-Only DNS
When using RODCs, it is possible to add the DNS role/service to the RODC. After the DNS service is added to an RODC, the RODC will replicate Active Directory–integrated DNS information such as DNS-related AD partitions, including both the ForestDNS and DomainDNS zones.
Running DNS on an RODC is very similar to running DNS on a writable domain controller. Users can query the local DNS server residing on the branch office RODC for A records and other DNS-related items such as Internet requests. However, unlike traditional writable domain controllers, DNS on RODC does not support dynamic updates. The DNS zone information is entirely read-only.
If a client wants to update their DNS A or PTR record in the local branch office, the RODC will send a DNS replicate-single-object change request to a writable domain controller running the traditional DNS service. The DNS change for the client will occur on the writable DNS server and, eventually, the change will be propagated back to the RODC via unidirectional Active Directory replication.
Read-Only SYSVOL
In Windows Server 2008, it was still possible for changes to be made to the sysvol folder of an RODC. When changes were made to the contents of the sysvol folder, those changes persisted until being overwritten by the next DFS Replication cycle. In Windows Server 2008 R2, Microsoft made changes to the RODC functionality such that the sysvol folder is now read-only on an RODC.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
Organizations’ Branch Office Concerns and Dilemmas
The next section illustrates typical branch office concerns about having domain controllers onsite. This section makes it evident why the RODC is becoming popular if not extremely necessary for branch offices.
Lack of Physical Security at the Branch Office
Typically, branch office locations do not have the facilities to host a data center. For that reason, it is common to find domain controllers hiding in closets, tucked away in the kitchen next to the fridge, or even in a restroom. As such, branch offices lack physical security when it comes to storing domain controllers, which results in these servers being prime targets for thieves.
Domain Controllers Stolen from the Branch Office
With inadequate physical security in the branch offices, it was very common for domain controllers to be stolen. This posed a major security threat to organizations because domain controllers contain a copy of all the user accounts associated with the domain. Confidential items such as highly privileged administrator accounts, DNS records, and the Active Directory schema could fall into the hands of the wrong people in this situation.
Removing Domain Controllers from the Branch Office
Because of a lack of physical security and concerns over domain controller theft, branch offices often had their domain controllers removed from their site. After being removed, users were forced to authenticate over the WAN to a domain controller residing at their corporate headquarters or to the closest hub site. Although this action solved the security issue, it also cultivated a new problem. If the WAN link between the branch office and hub site was unreliable or unavailable, users could not log on to the workstations at the branch office or the amount of time required to log on was greatly increased. This resulted in a loss of productivity for users in the branch office or outages that resulted in downtime if the WAN link was severed. These types of outages commonly lasted for days.
Lack of Administration Role Separation at the Branch Office
In small branch offices, it is also very common for multiple server functions to be hosted on a single server to reduce costs. For example, a single server might provide domain controller, file, print, messaging, and other line-of-business (LOB) functionality. In such cases, it is necessary for the administrators of these applications to log on to the system to manage their applications. By granting administrators privileges to the domain controller, these individuals also received full access to the Active Directory domain, which is considered to be a major security risk.
Lack of IT Support Personnel at the Branch Office
It is very common for secretaries, receptionists, or even high-level personnel such as managers and directors without any prior knowledge of IT management or maintenance to manage servers in a branch office. Typically, these individuals get nominated or promoted to a branch office IT support role because a local IT administrator does not exist. Unfortunately, even when conducting basic administration tasks like restarting an unresponsive server, these individuals can inadvertently wreak havoc on the Active Directory domain when granted administrator privileges on a domain controller. In a Windows Server 2003 environment, there was little that could be done about this situation. You just had to be careful about who you promoted to the exclusive club of domain administrators.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
Lack of Physical Security at the Branch Office
Typically, branch office locations do not have the facilities to host a data center. For that reason, it is common to find domain controllers hiding in closets, tucked away in the kitchen next to the fridge, or even in a restroom. As such, branch offices lack physical security when it comes to storing domain controllers, which results in these servers being prime targets for thieves.
Domain Controllers Stolen from the Branch Office
With inadequate physical security in the branch offices, it was very common for domain controllers to be stolen. This posed a major security threat to organizations because domain controllers contain a copy of all the user accounts associated with the domain. Confidential items such as highly privileged administrator accounts, DNS records, and the Active Directory schema could fall into the hands of the wrong people in this situation.
Removing Domain Controllers from the Branch Office
Because of a lack of physical security and concerns over domain controller theft, branch offices often had their domain controllers removed from their site. After being removed, users were forced to authenticate over the WAN to a domain controller residing at their corporate headquarters or to the closest hub site. Although this action solved the security issue, it also cultivated a new problem. If the WAN link between the branch office and hub site was unreliable or unavailable, users could not log on to the workstations at the branch office or the amount of time required to log on was greatly increased. This resulted in a loss of productivity for users in the branch office or outages that resulted in downtime if the WAN link was severed. These types of outages commonly lasted for days.
Lack of Administration Role Separation at the Branch Office
In small branch offices, it is also very common for multiple server functions to be hosted on a single server to reduce costs. For example, a single server might provide domain controller, file, print, messaging, and other line-of-business (LOB) functionality. In such cases, it is necessary for the administrators of these applications to log on to the system to manage their applications. By granting administrators privileges to the domain controller, these individuals also received full access to the Active Directory domain, which is considered to be a major security risk.
Lack of IT Support Personnel at the Branch Office
It is very common for secretaries, receptionists, or even high-level personnel such as managers and directors without any prior knowledge of IT management or maintenance to manage servers in a branch office. Typically, these individuals get nominated or promoted to a branch office IT support role because a local IT administrator does not exist. Unfortunately, even when conducting basic administration tasks like restarting an unresponsive server, these individuals can inadvertently wreak havoc on the Active Directory domain when granted administrator privileges on a domain controller. In a Windows Server 2003 environment, there was little that could be done about this situation. You just had to be careful about who you promoted to the exclusive club of domain administrators.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
Understanding Read-Only Domain Controllers (RODCs)
One of the new features that received close attention in Windows Server 2008 was a new breed of domain controllers referred to as Read-Only Domain Controllers, also known as RODCs. The RODC hosts a copy of the Active Directory (AD) database like any other writable domain controller, but as its name implies, the contents replica of the domain database residing on the domain controller is read-only and write operations are not supported. It is equally important to mention that the RODCs do not participate in Active Directory replication in the same fashion as writable domain controllers. The fundamental difference between RODC replication and the typical multimaster replication model between writable domain controllers is that RODC replication is unidirectional. This means all changes from a writable domain controller are propagated to the RODCs. As a result, the RODC receives changes, but does not partake in or perform outbound replication with other domain controllers. This characteristic of RODCs provides an extra layer of security as any unauthorized data changes, especially changes made with the intent to hurt the organization, will not replicate out to other domain controllers. Unidirectional replication also reduces the workload of bridgehead servers in the hub site and the effort required to monitor replication.
Another new RODC functionality that improves security is commonly witnessed when replication transpires between a writable domain controller and an RODC. Here, user account information is replicated, but account passwords are not replicated. This is a new phenomenon because of the existence of Windows domain controllers. Security is bolstered in this situation as the only password that resides on the RODC is the local administrator’s password and Krbtgt accounts (the account used for Kerberos authentication). In essence, the read-only philosophy of an RODC is similar to the NT 4.0 Backup Domain Controller (BDC); however, with the NT 4.0 BDC, all user information is replicated from the Primary Domain Controller (PDC), including passwords. Although Microsoft fields numerous questions on this new Active Directory technology, the question that is asked the most is where does the RODC fit in? RODCs are most often used to provide Active Directory Domain Services (AD DS) to remote locations and branch offices where heightened security is essential, where Windows Active Directory administrators are lacking, and where the promise of physical security is practically nonexistent. In many cases, RODCs offer a practical headache-free solution for branch office environments that in the past had to endure solutions that always put them in compromising
situations. If needed, it is also possible to configure credential caching of passwords for a specific user account to an RODC. Moreover, by default, security groups with high privileges such as Domain Administrators and Enterprise Administrators are configured to never allow their passwords to replicate to RODCs.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
Another new RODC functionality that improves security is commonly witnessed when replication transpires between a writable domain controller and an RODC. Here, user account information is replicated, but account passwords are not replicated. This is a new phenomenon because of the existence of Windows domain controllers. Security is bolstered in this situation as the only password that resides on the RODC is the local administrator’s password and Krbtgt accounts (the account used for Kerberos authentication). In essence, the read-only philosophy of an RODC is similar to the NT 4.0 Backup Domain Controller (BDC); however, with the NT 4.0 BDC, all user information is replicated from the Primary Domain Controller (PDC), including passwords. Although Microsoft fields numerous questions on this new Active Directory technology, the question that is asked the most is where does the RODC fit in? RODCs are most often used to provide Active Directory Domain Services (AD DS) to remote locations and branch offices where heightened security is essential, where Windows Active Directory administrators are lacking, and where the promise of physical security is practically nonexistent. In many cases, RODCs offer a practical headache-free solution for branch office environments that in the past had to endure solutions that always put them in compromising
situations. If needed, it is also possible to configure credential caching of passwords for a specific user account to an RODC. Moreover, by default, security groups with high privileges such as Domain Administrators and Enterprise Administrators are configured to never allow their passwords to replicate to RODCs.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
Optimizing Windows Server 2008 R2 for Branch Office Communications
Today’s organizations are likely to consist of many branch offices. On average, a branch office is a small office hosting fewer than 50 employees in a remote location. Typically, a branch office infrastructure is connected to the headquarters site, centralized data center, or hub site by means of a wide area network (WAN) link in a distributed fashion. Due to the high costs associated with purchasing bandwidth, these WAN links are usually slow, unreliable, and inefficient. Finally, most branch offices lack physical security and IT support personnel.
For many organizations, maintaining branch offices generates significant operational costs and administrative challenges. Two scenarios exist when dealing with branch offices because of the high costs of securing high-speed links between the branch office and hub site. Either the organization implements server infrastructure at the branch office or IT services are provided to the branch office from a centralized site such as the company headquarters.
By providing branch offices with their own infrastructure productivity increases; however, operational and management costs typically rise. When providing services to a branch office from a centralized site, its productivity is reduced as all branch office users must obtain services over a slow and unreliable WAN link. In addition, if the WAN link becomes unavailable, productivity at the branch office can come to a halt until the WAN link is repaired. As you can see, each scenario has cost and efficiency trade-offs.
Challenges like the one just described might, however, become a thing of the past for branch offices. Windows Server 2008 R2 provides new technology solutions that allow organizations to integrate branch offices seamlessly into the organization’s infrastructure.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
For many organizations, maintaining branch offices generates significant operational costs and administrative challenges. Two scenarios exist when dealing with branch offices because of the high costs of securing high-speed links between the branch office and hub site. Either the organization implements server infrastructure at the branch office or IT services are provided to the branch office from a centralized site such as the company headquarters.
By providing branch offices with their own infrastructure productivity increases; however, operational and management costs typically rise. When providing services to a branch office from a centralized site, its productivity is reduced as all branch office users must obtain services over a slow and unreliable WAN link. In addition, if the WAN link becomes unavailable, productivity at the branch office can come to a halt until the WAN link is repaired. As you can see, each scenario has cost and efficiency trade-offs.
Challenges like the one just described might, however, become a thing of the past for branch offices. Windows Server 2008 R2 provides new technology solutions that allow organizations to integrate branch offices seamlessly into the organization’s infrastructure.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
Project Management Office (PMO)
In recent years, many organizations have introduced Project Management Offices (PMOs) into their business operations. A PMO is used to provide somewhat of a project oversight committee to organizations that frequently operate several projects simultaneously.
Organizations that utilize a proven project methodology can further extend this methodology to include workflow processes that include checkpoints with the PMO staff.
The role of the PMO can be different in almost every organization, but most include a few key functions. The role of the PMO usually involves reviewing proposed projects to determine how or if the project deliverables coincide with the organization’s current or future business plans or strategies. PMO membership can also be very different among organizations. PMO membership can include departmental managers, directors or team leads, executive staff, employee advocates, and, in some cases, board members. Having the PMO staff represent views and insight from the different levels and departments of an organization enables the PMO to add value to any proposed project.
Having diverse staff included in the PMO staff enables the organization to evaluate and understand current and proposed projects and how these projects will positively or negatively affect the organization as a whole. Some of the general functions or roles a PMO can provide include the following:
. High-level project visibility—All proposed projects are presented to the PMO and if approved, the project is tracked by the PMO. This provides a single entity that is knowledgeable and informed about all ongoing and future projects in an organization and how they align to business and technical objectives.
. Project sounding board—When a new project is proposed or presented to the PMO, the project will be scrutinized and many questions will be asked. Some of these questions might not have been considered during the initial project design and planning phases. The PMO improves project quality by constantly reviewing and monitoring projects from when the project is proposed and during regular scheduled project status and PMO meetings.
. Committee-based project approval or denial—The PMO is informed of all the current and future projects, as well as business direction and strategy, and is the best equipped group to decide on whether a project should be approved, denied, or postponed.
. Enterprise project management—The PMO tracks the status of all ongoing projects and upcoming projects, which enables the PMO to provide additional insight and direction with regard to internal resource utilization, vendor management for outsourced projects, and, of course, project budget and scheduling.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
Organizations that utilize a proven project methodology can further extend this methodology to include workflow processes that include checkpoints with the PMO staff.
The role of the PMO can be different in almost every organization, but most include a few key functions. The role of the PMO usually involves reviewing proposed projects to determine how or if the project deliverables coincide with the organization’s current or future business plans or strategies. PMO membership can also be very different among organizations. PMO membership can include departmental managers, directors or team leads, executive staff, employee advocates, and, in some cases, board members. Having the PMO staff represent views and insight from the different levels and departments of an organization enables the PMO to add value to any proposed project.
Having diverse staff included in the PMO staff enables the organization to evaluate and understand current and proposed projects and how these projects will positively or negatively affect the organization as a whole. Some of the general functions or roles a PMO can provide include the following:
. High-level project visibility—All proposed projects are presented to the PMO and if approved, the project is tracked by the PMO. This provides a single entity that is knowledgeable and informed about all ongoing and future projects in an organization and how they align to business and technical objectives.
. Project sounding board—When a new project is proposed or presented to the PMO, the project will be scrutinized and many questions will be asked. Some of these questions might not have been considered during the initial project design and planning phases. The PMO improves project quality by constantly reviewing and monitoring projects from when the project is proposed and during regular scheduled project status and PMO meetings.
. Committee-based project approval or denial—The PMO is informed of all the current and future projects, as well as business direction and strategy, and is the best equipped group to decide on whether a project should be approved, denied, or postponed.
. Enterprise project management—The PMO tracks the status of all ongoing projects and upcoming projects, which enables the PMO to provide additional insight and direction with regard to internal resource utilization, vendor management for outsourced projects, and, of course, project budget and scheduling.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
Volume Shadow Copy Service (VSS)
Window Server 2008 R2 Volume Shadow Copy Service (VSS) provides some great features that can be used to enhance backup and recovery for Windows disks. One great feature of VSS, called Shadow Copies for Shared Volumes, captures and stores copies of the files and folders at a specific point in time.
Administrators and end users with the correct permissions can browse the shadow copies based on the time and date of creation and essentially restore a specific folder, file, or entire volume without restoring from tape. The shadow copies are very space efficient, as the first copy is a complete compressed version of the data on the volume, and subsequent copies store only the changes made since the last shadow copy was created.
Another great feature of the VSS is the tight integration it provides for third-party software vendors and to the Windows Server Backup tools. VSS enables manual backups created using Windows Server Backup to store shadow copies on remote server shares. Windows Server Backup also utilizes VSS to manage the storage space of the backup by using the space-efficient and intelligent storage functions of VSS.
Enabling Shadow Copies for Shared Volumes
Enabling shadow copies on a volume can be very simple. Administrators have more options when it comes to recovering lost or deleted data and, in many cases, can entirely avoid restoring data to disk from a backup tape device or tape library. In addition, select users can be given the necessary rights to restore files that they’ve accidentally deleted.
The Volume Shadow Copy Service is already installed and is automatically available using NTFS-formatted volumes.
To enable and configure shadow copies, follow these steps:
1. Log on to the Windows Server 2008 R2 system with an account with administrator privileges.
2. Click Start, click All Programs, click Administrative Tools, and select Server Manager.
3. In the tree pane, double-click the Storage node, and select Disk Management.
4. In the tasks pane, scroll down to locate the desired volume, right-click the volume, and select Properties.
5. Select the Shadow Copies tab; in the Select a Volume section, click on the desired volume, and click the Settings button.
6. The Settings page enables you to choose an alternate volume to store the shadow copies. Select the desired volume to store the shadow copy and set the storage space limit for the volume. The default is usually set to 10% of the volume size.
7. After the location and maximum size are configured, click the Schedule button and define the schedule. The defaults create a shadow copy at 7:00 a.m. and 12:00 p.m.
8. Click OK to close the Schedule window, and click OK again to close the Volume Shadow Copy Settings window. The shadow copy for the originally selected volume is now enabled.
9. If necessary, select the next volume and enable shadow copying; otherwise, select the enabled volume and immediately create a shadow copy by clicking the Create Now button.
10. If necessary, select the next volume and immediately create a shadow copy by clicking the Create Now button.
11. After the shadow copies are created, click OK to close the Shadow Copies page, close the Server Manager, and log off of the server.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
Administrators and end users with the correct permissions can browse the shadow copies based on the time and date of creation and essentially restore a specific folder, file, or entire volume without restoring from tape. The shadow copies are very space efficient, as the first copy is a complete compressed version of the data on the volume, and subsequent copies store only the changes made since the last shadow copy was created.
Another great feature of the VSS is the tight integration it provides for third-party software vendors and to the Windows Server Backup tools. VSS enables manual backups created using Windows Server Backup to store shadow copies on remote server shares. Windows Server Backup also utilizes VSS to manage the storage space of the backup by using the space-efficient and intelligent storage functions of VSS.
Enabling Shadow Copies for Shared Volumes
Enabling shadow copies on a volume can be very simple. Administrators have more options when it comes to recovering lost or deleted data and, in many cases, can entirely avoid restoring data to disk from a backup tape device or tape library. In addition, select users can be given the necessary rights to restore files that they’ve accidentally deleted.
The Volume Shadow Copy Service is already installed and is automatically available using NTFS-formatted volumes.
To enable and configure shadow copies, follow these steps:
1. Log on to the Windows Server 2008 R2 system with an account with administrator privileges.
2. Click Start, click All Programs, click Administrative Tools, and select Server Manager.
3. In the tree pane, double-click the Storage node, and select Disk Management.
4. In the tasks pane, scroll down to locate the desired volume, right-click the volume, and select Properties.
5. Select the Shadow Copies tab; in the Select a Volume section, click on the desired volume, and click the Settings button.
6. The Settings page enables you to choose an alternate volume to store the shadow copies. Select the desired volume to store the shadow copy and set the storage space limit for the volume. The default is usually set to 10% of the volume size.
7. After the location and maximum size are configured, click the Schedule button and define the schedule. The defaults create a shadow copy at 7:00 a.m. and 12:00 p.m.
8. Click OK to close the Schedule window, and click OK again to close the Volume Shadow Copy Settings window. The shadow copy for the originally selected volume is now enabled.
9. If necessary, select the next volume and enable shadow copying; otherwise, select the enabled volume and immediately create a shadow copy by clicking the Create Now button.
10. If necessary, select the next volume and immediately create a shadow copy by clicking the Create Now button.
11. After the shadow copies are created, click OK to close the Shadow Copies page, close the Server Manager, and log off of the server.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
Certificate Services
When the Active Directory Certificate Services role and role servers are installed on a Windows Server 2008 R2 system, a Certification Authority is created. The Certification Authority or CA is used to manage and allocate certificates to users, servers, and workstations when files, folders, email, or network communication needs to be secured or encrypted.
When the CA allocates a certificate to a machine or user, that information is recorded in the certificate database on the local drive of the CA. If this database is corrupted or deleted, all certificates allocated from this server become invalid or unusable. To avoid this problem, the certificates and Certificate Services database should be backed up frequently. Even if certificates are rarely allocated to new users or machines, backups should still be performed regularly. The certificate authority database is backed up with a full system backup but can be backed up using the Certification Authority console. To perform a manual backup of the certificate authority, perform the following steps:
1. Log on to the Windows Server 2008 R2 Certification Authority server system with an account with administrator privileges.
2. Click Start, click All Programs, click Administrative Tools, and select Certification Authority.
3. Double-click on the Certification Authority server to initiate the connection in the console.
4. Right-click on the server, click All Tasks, and select Back Up CA.
5. When the Certification Authority Backup Wizard opens, click Next on the welcome page.
6. On the Items to Back Up page, check both check boxes, and in the Back Up to This Location text box, type c:\Windows\System32\CABackup\ and click Next.
7. A window opens stating that the destination folder does not exist; click OK to create the folder and continue.
8. On the Select a Password page, enter a password, confirm the password, and click Next to continue. This password is very important because it will be required to restore the database should that be necessary—so store this password in a safe place.
9. On the Completing the Certification Authority Backup Wizard page, review the settings, and click Finish to create the backup.
10. After the backup completes, the focus is returned to the Certification Authority console. Close the console.
11. Log off of the server.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
When the CA allocates a certificate to a machine or user, that information is recorded in the certificate database on the local drive of the CA. If this database is corrupted or deleted, all certificates allocated from this server become invalid or unusable. To avoid this problem, the certificates and Certificate Services database should be backed up frequently. Even if certificates are rarely allocated to new users or machines, backups should still be performed regularly. The certificate authority database is backed up with a full system backup but can be backed up using the Certification Authority console. To perform a manual backup of the certificate authority, perform the following steps:
1. Log on to the Windows Server 2008 R2 Certification Authority server system with an account with administrator privileges.
2. Click Start, click All Programs, click Administrative Tools, and select Certification Authority.
3. Double-click on the Certification Authority server to initiate the connection in the console.
4. Right-click on the server, click All Tasks, and select Back Up CA.
5. When the Certification Authority Backup Wizard opens, click Next on the welcome page.
6. On the Items to Back Up page, check both check boxes, and in the Back Up to This Location text box, type c:\Windows\System32\CABackup\ and click Next.
7. A window opens stating that the destination folder does not exist; click OK to create the folder and continue.
8. On the Select a Password page, enter a password, confirm the password, and click Next to continue. This password is very important because it will be required to restore the database should that be necessary—so store this password in a safe place.
9. On the Completing the Certification Authority Backup Wizard page, review the settings, and click Finish to create the backup.
10. After the backup completes, the focus is returned to the Certification Authority console. Close the console.
11. Log off of the server.
Source of Information : Sams - Windows Server 2008 R2 Unleashed
Subscribe to:
Posts (Atom)
Cloud storage is for blocks too, not just files
One of the misconceptions about cloud storage is that it is only useful for storing files. This assumption comes from the popularity of file...
-
Smss is like any other user-mode process except for two differences: First, Windows considers Smss a trusted part of the operating system. S...
-
When Winload calls Ntoskrnl, it passes a data structure called the loader parameter block that contains the system and boot partition paths,...
-
Many of the virus, adware, security, and crash problems with Windows occu when someone installs a driver of dubious origin. The driver suppo...