Active Directory Certificate Services

Features in AD CS

By using Server Manager, you can install the following components of AD CS:

• Certification authorities (CAs). Root and subordinate CAs are used to issue certificates to users, computers, and services, and to manage certificate validity.
  
• CA Web enrollment. Web enrollment allows users to connect to a CA by means of a Web browser in order to request certificates and retrieve certificate revocation lists (CRLs).
  
• Online Responder. The Online Responder service accepts revocation status requests for specific certificates, evaluates the status of these certificates, and sends back a signed response containing the requested certificate status information.
  
• Network Device Enrollment Service. The Network Device Enrollment Service allows routers and other network devices that do not have domain accounts to obtain certificates.
  
• Certificate Enrollment Web Service. The Certificate Enrollment Web Service enables users and computers to perform certificate enrollment that uses the HTTPS protocol. Together with the Certificate Enrollment Policy Web Service, this enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain.
  
• Certificate Enrollment Policy Web Service. The Certificate Enrollment Policy Web Service enables users and computers to obtain certificate enrollment policy information. Together with the Certificate Enrollment Web Service, this enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain.
  

Benefits of AD CS

Organizations can use AD CS to enhance security by binding the identity of a person, device, or service to a corresponding private key. AD CS gives organizations a cost-effective, efficient, and secure way to manage the distribution and use of certificates.
Applications supported by AD CS include Secure/Multipurpose Internet Mail Extensions (S/MIME), secure wireless networks, virtual private network (VPN), Internet Protocol security (IPsec), Encrypting File System (EFS), smart card logon, Secure Socket Layer/Transport Layer Security (SSL/TLS), and digital signatures.
The new features of AD CS in Windows Server 2008 R2 include:

• Certificate enrollment that uses the HTTPS protocol.
  
• Certificate enrollment across Active Directory Domain Services (AD DS) forest boundaries.
  
• Improved support for high-volume certificate issuance.
  
• Support for CAs on a Server Core installation of Windows Server 2008 R2.
  

Hardware and software considerations

Although AD CS can be deployed on a single server, many deployments will include multiple servers configured as CAs, other servers configured as Online Responders, and others serving as Web enrollment portals. CAs can be installed on servers running a variety of operating systems, including Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, and Windows 2000 Server. However, not all operating systems support all features or design requirements, and creating an optimal design will require careful planning and testing before you deploy AD CS in a production environment.

Installing AD CS

After you finish installing the operating system, you can use Server Manager to set up a CA and other optional components.
Additional configuration steps need to be completed by using the appropriate snap-ins before a CA or Online Responder is functional. For more information, refer to the related Help topics for the Certification Authority snap-in and the Online Responder snap-in.

Managing AD CS

You can use either Server Manager or Microsoft Management Console (MMC) snap-ins to manage AD CS role services. Use the following steps to open the snap-ins:

• To manage a CA, use the Certification Authority snap-in. To open the Certification Authority snap-in, click Start, click Run, type certsrv.msc, and click OK.
  
• To manage certificates, use the Certificates snap-in. To open the Certificates snap-in, click Start, click Run, type certmgr.msc, and click OK.
  
• To manage certificate templates, use the Certificate Templates snap-in. To open the Certificate Templates snap-in, click Start, click Run, type certtmpl.msc, and click OK.
  
• To manage an Online Responder, use the Online Responder snap-in. To open the Online Responder snap-in, click Start, click Run, type ocsp.msc, and click OK.

Source:
www.technet.microsoft.com

Published By
S.G.Godwin Dinesh.MCA
Sr.System Administrator

Active Directory Lightweight Directory Services

For organizations that require flexible support for directory-enabled applications, Microsoft has developed Active Directory Lightweight Directory Services (AD LDS). AD LDS is a Lightweight Directory Access Protocol (LDAP) directory service.
AD LDS provides data storage and retrieval for directory-enabled applications, without the dependencies that are required for Active Directory Domain Services (AD DS). AD LDS provides much of the same functionality as AD DS, but it does not require the deployment of domains or domain controllers. You can run multiple instances of AD LDS concurrently on a single computer, with an independently managed schema for each AD LDS instance.

What's new in AD LDS

The following features are new to AD LDS in Windows Server 2008 R2:

• The AD LDS server role
  
• Integration with AD DS

Microsoft directory technologies

With AD LDS, Microsoft provides a choice of directory services. Both AD LDS and AD DS build on the same core Microsoft directory service technologies, but they address different needs in an organization.
AD DS provides directory services for both the Windows server operating system and for directory-enabled applications. For the server operating system, AD DS stores critical information about the network infrastructure, users and groups, network services, and so on. In this role, AD DS must adhere to a single schema throughout an entire forest.
AD LDS provides directory services specifically for directory-enabled applications. AD LDS does not require or rely on AD DS domains or forests. However, in environments where AD DS exists, AD LDS can use AD DS for the authentication of Windows security principals.
AD LDS and AD DS can run concurrently in the same network. In addition, AD LDS can support both domain users and workgroup users simultaneously, as shown in the following illustration.

Directory-enabled applications

A directory-enabled application uses a directory, rather than (or in addition to) a database, flat file, or other data storage structure, to hold its data. Many off-the-shelf applications, as well as many custom applications, use a directory-enabled design. Examples of the types of applications that often use a directory-enabled design include customer relationship management (CRM) applications, human resource (HR) applications, and global address book applications.
Directory services (such as AD LDS) and relational databases both provide data storage and retrieval, but they differ in their optimization. Directory services are optimized for read processing, while relational databases are optimized for transaction processing. In general, consider implementing a directory service if your application reads data more frequently than it writes data. Consider implementing a relational database if your application writes or modifies data more frequently than it reads data.
In addition, directory services also provide such benefits as distributed architecture (multimaster design, replication, and geographical scalability); storage of identity data that is common to applications and platforms throughout an enterprise; flexible data schema; and fine-grained access policies.

Source:
www.technet.microsoft.com


Published By
S.G.Godwin Dinesh.MCA
Sr.System Administrator

Placing Active Directory Domain Services Files

When you install Active Directory Domain Services (AD DS), you specify where the Active Directory database, log files, and the SYSVOL shared folder will be placed on the server. The database stores information about the users, computers, and other objects on the network. The log files record activities that are related to AD DS, such as information about an object being updated. SYSVOL stores Group Policy objects and scripts. By default, SYSVOL is part of the operating system files in the %windir% directory.

Consider the following factors when you decide where to place AD DS files:
Backup and recovery
Performance
Backup and recovery considerations for placing AD DS files For a simple installation in which the server has only one hard disk, you can simply accept the default installation settings that are supplied by the Active Directory Domain Services Installation Wizard. However, you must create at least two volumes on that one hard disk. One volume is required for critical-volume data and another volume is required for backup.

When you use Windows Server Backup or the Wbadmin.exe command-line tool to back up a domain controller, you must back up at least the system state data so that you can use the backup to recover the server. The volume that you use to store the backups cannot be the same volume that hosts system state data. This requirement can affect where you decide to place AD DS files. The system components that make up system state data depend on the server roles that are installed on the computer. The system state data includes at least the following data, plus additional data, depending on the server roles that are installed:

Registry

COM+ Class Registration database

Boot files

Active Directory Certificate Services (AD CS) database

Volume that hosts the Active Directory database (Ntds.dit)

Volume that hosts the Active Directory database log files

SYSVOL directory

Cluster service information

Microsoft Internet Information Services (IIS) metadirectory

System files that are under Windows Resource Protection

For example, if you are installing AD DS on a server that has one hard disk, you might create the following logical volumes to accommodate backups:

Drive C, which hosts all the critical volume data


Drive D, which is used as a target for Windows Server Backup or Wbadmin.exe


For more information about backing up and recovering a domain controller, see the Step-by-Step Guide for Active Directory Domain Services Backup and Recovery (http://go.microsoft.com/fwlink/?LinkId=93077).

Performance considerations for placing AD DS files
For more complex installations, you may configure your hard disk storage to optimize the performance of AD DS. Because the database and log files utilize disk storage space in different ways, you can improve AD DS performance by devoting separate hard disk spindles for each.

For example, suppose that a server has four available hard disk drives that are labeled as follows:

Drive C, which includes the operating system files

Drive D, which is not used

Drive E, which is not used

Drive F, which is used for backup

On this server, you can improve AD DS performance the most by installing the database and log files on separate drives that are devoted to those resources, such as drives D and E. This can help improve the performance of searches against the database because one disk spindle can be devoted solely to that activity. If a large number of changes are ever made at one time, this configuration also reduces the chance of bottlenecks developing on the disk that hosts the log files. You can place SYSVOL on drive C with the operating system files.



Published By
S.G.Godwin Dinesh.MCA
Sr.System Administrator

How to set up a Windows Server 2012 VPN

We will seeing how to setup a Windows Server 2012 as a VPN server. Not many must be aware that Windows has this feature built in in both its Server ans Desktop Operating Systems. For setting up a VPN server a windows 7 machine, go check it here.
Well the prerequisite is here that you need a Windows Server 2012 R2 installed to follow along this article. Note that the steps are different for a Windows Server 2008 machine.

Install the Remote Access Server Role

We will be doing this through a GUI. Open Server Manger and click on Manage and select Add Roles and Features.

A wizard comes up, select Next and click on Roles based or feature based installation and click on Next.
On the next page select the destination server, which is the local machine.

Select the Remote Access Role on the next page and click on Next.

It will by default install the required features like .NET framework, click on Next. The next page will give you a brief introduction about the Remote Access role, go through it and click on Next.
On the next page, select Direct Access and VPN Role services because this is what we are interested in. It will prompt to install the required features, click on Add Features and Next.


It also requires Web Server to be installed, you are fine by just selecting the defaults and clicking on Next.

Click on Install and wait for the installation to complete.

Configure the Remote Access Server Role

Now that we are done with installing the Server Role, we need to go enable it and provide a few details to start accepting the incoming connections.
From Administrative Tools, select Remote and Routing Access. A window comes up, right click on the server and select Configure and Enable and Remote and Routing Access.

A wizard pops up and follow along.

Select Custom Configuration and click on Next.

On the next page, select VPN server and click on Finish.


Next step will be to start the services.

Now Right click on the server and click on Properties to configure the IP addresses that it will give out once the connections are made.

Now you will need to allow the connections coming in on the Windows Firewall. Go to start and type Firewall and select the third option as shown below.

Make sure that the connections are allowed for Remote Access as seen below.

That’s it! You are done. Before you can receive connections you will have to configure your Firewall.

Configure Perimeter Firewall

Based on the type of firewall you have, ensure the following ports are allowed traffic to the RRAS server:
PPTP Connections:
TCP 1723
L2TP/IPSec Connections:
TCP 1701
UDP 500
SSTP Connections:
TCP 443

Published By
S.G.Godwin Dinesh

8 Configure Failover Clusters for Windows Server 2012 R2

This topic provides an overview of the Failover Clustering feature inWindows Server 2012 R2 and Windows Server 2012. Failover clusters provide high availability and scalability to many server workloads.

These include server applications such as Microsoft Exchange Server,Hyper-V, Microsoft SQL Server, and file servers. The server applications can run on physical servers or virtual machines. This topic describes the Failover Clustering feature and provides links to additional guidance about creating, configuring, and managing failover clusters that can scale to 64 physical nodes and to 8,000 virtual machines.


The process for building your cloud infrastructure uses a combination of Hyper-V, failover clustering, storage, and networking technologies to more easily create a Microsoft cloud infrastructure. Windows Server 2012 introduces a significant number of new features that provide all of the required capabilities for building an effective cloud infrastructure in an open platform. By using automation, having an open platform, and being standards based, a Windows Server 2012-based cloud infrastructure decreases the total cost of ownership and reduces susceptibility tofailures due to interoperability issues. The Windows Server 2012 open platform allows partners to extend the functionality beyond what is in the platform.

Source:

www.technet.microsoft.com



Published By

S.G.Godwin Dinesh.MCA

Sr.System Administrator

8 Configure Failover Clusters for Windows Server 2012 R2

This topic provides an overview of the Failover Clustering feature in
Windows Server 2012 R2 and Windows Server 2012. Failover clusters
provide high availability and scalability to many server workloads.
These include server applications such as Microsoft Exchange Server,
Hyper-V, Microsoft SQL Server, and file servers. The server applications
can run on physical servers or virtual machines. This topic describes
the Failover Clustering feature and provides links to additional
guidance about creating, configuring, and managing failover clusters
that can scale to 64 physical nodes and to 8,000 virtual machines.

The process for building your cloud infrastructure uses a combination of
Hyper-V, failover clustering, storage, and networking technologies to
more easily create a Microsoft cloud infrastructure. Windows Server 2012
introduces a significant number of new features that provide all of the
required capabilities for building an effective cloud infrastructure in
an open platform. By using automation, having an open platform, and
being standards based, a Windows Server 2012-based cloud infrastructure
decreases the total cost of ownership and reduces susceptibility to
failures due to interoperability issues. The Windows Server 2012 open
platform allows partners to extend the functionality beyond what is in
the platform.



Source:

www.technet.microsoft.com



Published By

S.G.Godwin Dinesh.MCA
Sr.System Administrator

Microsoft System Center 2012 R2 Windows Server 2012 R2 Private Cloud Ove...

System
Center enables the Microsoft Cloud OS by delivering unified management
across on-premises, service provider, and Microsoft Azure environments.

Application focused

System Center
enables easy workload portability between Windows Server and Microsoft
Azure. It helps you deliver predictable line-of-business application
SLAs by providing deep insight and diagnostics for your .NET and Java
applications. Global Service Monitor and System Center Advisor deliver
application health and performance insights from Microsoft Azure. System
Center helps you provision your apps faster and repeatably using
service templates. Your application developers and operations staff can
help you take applications to market faster through built-in System
Center-Visual Studio dev-ops integration. Finally, System Center
provides your application owners with a unified, self-service view
across clouds.

Enterprise-class

System Center 2012 R2
delivers best-in-class management for Windows Server environments that
your critical business applications run on. It provides extensive
built-in knowledge to help you optimize performance and availability for
first-party Microsoft workloads like Exchange, SQL, and SharePoint.
System Center helps you bridge physical and virtual networks, thereby
enabling flexible

workload mobility in hybrid environments. It
can help you optimize your investments in SAN storage. System Center
also provides robust heterogeneous datacenter management, including
multiple hypervisors and Linux support. Finally, System Center enables
unified monitoring for your on-premises and Microsoft Azure
infrastructure, helping you to extend your existing investments and
skill-sets.

Simple and cost-effective

To make it easier
to deploy, we deliver service templates and runbooks for System Center
components. You can easily integrate System Center capabilities with
your existing management tools through the built-in web-service
interfaces and Integration Packs. System Center can help you optimize
storage cost-performance for your business-critical workloads by
effectively managing Windows Server file-based storage and Storage
Spaces. It also provides extensible automation and integration, thereby
helping you to operate your infrastructure in a cost-effective and
predictable manner.

Differences between Authenticated Users, Domain Users, and Everyone groups

Information: The following explains the difference between Authenticated Users, Domain Users, and Everyone groups. Domain Users Of the three groups listed Domain Users is the only actual group.  By that I mean you can add and remove members from this group.  Domain Users is a Global Group in the domain, and it can only contain users that are members of same domain the Domain Users group resides in.  By default all users created in the domain are automatically members of this group.  However, the default Guest account in the domain is not a member of this group, instead it is placed in the Domain Guest group The SID for Domain Users is S-1-5--513.  The Domain Users group can be added to other domain groups, and can be given permissions directly to objects, as well as placed in Local computer groups. Because Domain Users normally contains only user accounts and can be directly controlled by the administrator it is generally considered the most secure group of the three listed. Authenticated Users Authenticated Users was first introduced in Windows NT 4.0 SP3.  This is a built-in group that cannot be modified.  The Authenticated Users group contains users who have authenticated to the domain or a domain that is trusted by the computer domain.  For this reason it is generally thought of as the sum of all Domain User groups the computer’s domain has a trust with.  However, Authenticated Users will contain all manually created user accounts in all trusted domains regardless of whether they are a member of the Domain Users group or not.  Authenticated Users specifically does not contain the built-in Guest account, but will contain other users created and added to Domain Guests. The Authenticated Users group also includes the local computer account (computername$) and the built-in SYSTEM account.  Because of this the Authenticated Users also contains the domain computer accounts (domain\computername$) from all trusted domains.  The local computer account is always a member of the Authenticated Users group even when disconnected from the network.  However, just like Domain Users, the local computer account must first authenticate to the domain to be considered part of the Authenticated Users token when connecting remotely to other computers within its trusted domains.  This membership can be verified by using the gpresult.exe and looking at the following line. The computer is a part of the following security groups: --------------------------------------------------------     BUILTIN\Administrators     Everyone     BUILTIN\Users     NT AUTHORITY\NETWORK     NT AUTHORITY\Authenticated Users                               The SID for Authenticated Users is S-1-5-11.  Authenticated Users is available when applying permissions directly to an object, or can be placed in Built-in and user created Local computer groups.  Authenticated Users cannot be added as a member to another user created domain groups (Global, Domain Local, or Universal).  However, the Authenticated Users group can be added to the Built-in Domain Local groups.   When working with domain user accounts and local user accounts remember that the local user accounts will also be members of Authenticated Users, and will therefore have access to local resources secured with this permission.  However, the scope of the local user accounts’ access will not extend onto remote computers via the Authenticated Users group.  This is because while the local user account includes the SID for the Authenticated User group, the local user must still authenticate to any remote computer prior to access being granted. By default the Authenticated Users group is automatically added to the Built-in\Users group on all workstations when added to the domain. Because Authenticated Users automatically includes all domain user accounts from all current and future trusted domains it is considered the most administrator friendly, allowing a good balance between security and future needs or changes. Everyone group The Everyone group includes all members of the Domain Users, Authenticated Users group as well as the built-in Guest account, and several other Built-in security identifiers like SERVICE, LOCAL_SERVICE, NETWORK_SERVICE, etc.  NULL session connections (aka anonymous logon) used to be included in this group but were removed in Windows 2003.  This is a built-in group that cannot be modified. The SID for the Everyone group is S-1-1-0.  The Everyone group is available when applying permissions directly to an object, or can be placed in Built-in and user created Local computer groups.  The Everyone group cannot be added as a member to another user created domain groups (Global, Domain Local, or Universal).  However, the Everyone group can be added to the Built-in Domain Local groups. Because the Everyone group contains the Guest account, and several other Built-in security identifiers like SERVICE, LOCAL_SERVICE, NETWORK_SERVICE, etc. it is generally considered the least secure of the three groups. A common misconception of the Everyone group is that it includes unauthenticated users or users from un-trusted domains and workstations (ie. anonymous users).  This implies that any user account from any un-trusted domain or workstation can access the resource that is being secured using the Everyone group.  This is not true.  To be included in the Everyone group requires that the computer account or user account be a member of the domain or a trusted domain.  User accounts on un-trusted workstations (i.e. consultant laptop) may not access resources secured by the Everyone group that are hosted on another computer without first authenticating with a domain or local user account. Published By S.G.Godwin Dinesh.MCA Sr.System Administrator

IPv4 & IPv6 Reverse Lookup Zone Configuration

Configuring Reverse Lookup Zones for IPv4
Now, we need to create a matching reverse lookup zone. This will handle reverse resolution for our subnet. In this case, it is 192.168.1.x.
1. Choose Start Administrative Tools DNS.
2. In the console tree, click Reverse Lookup Zones.
3. Right-click Reverse Lookup Zones, and then click New Zone.
4. When the New Zone Wizard appears, click Next.
5. On the Zone Type page, select Primary Zone, and then click Next.
6. On the Reverse Lookup Zone Name page, make sure IPv4 is selected, and then click Next.
7. On the Reverse Lookup Zone Name page, in the Network ID field, type the start of the subnet range of your network (in this case, 192.168.1.x), and then click Next.
8. On the Zone File page, click Next.
9. On the Dynamic Update page, click Next.
10. On the Completing The New Zone Wizard page, click Finish.

Configuring Reverse Lookup Zones for IPv6
1. In the console tree, click Reverse Lookup Zones.
2. Right-click Reverse Lookup Zones, and then click New Zone.
3. When the New Zone Wizard appears, click Next.
4. On the Zone Type page, select Primary Zone, and then click Next.
5. On the Reverse Lookup Zone Name page, make sure IPv6 is selected, and then click Next.
6. In the Reverse Lookup Zone Name field, type in the prefix, and then click Next.
7. On the Dynamic Update page, choose Allow Both Nonsecure And Secure Dynamic Updates, and click Next.
8. Click Finish to create the New Zone.



Create IPv6 Record:
1.Rright-click the Primary Lookup Zone for your domain, and then click New Host.
2. In the Name field, enter the name of your server or ws.
3. In the IP address field, enter the IPv6 address we set for the server.
4. Verify that Create Associated Pointer (PTR) Record is checked, and click Add Host.
You should now see a new AAAA record for the server, as well as a new PTR record in the Reverse Lookup Zone we created.

Published By
S.G.Godwin Dinesh.MCA
Sr.System Administrator

Microsoft Windows Server 2008 R2 Sp1 Disk Quota Management

Setting Disk Quotas

Windows Server 2008 supports two mutually exclusive methods for
setting quotas on the amount of file system resources a user can
use—disk quotas or directory quotas. Disk quotas were introduced in
Windows 2000, and are applied to specific users and limit the amount of
disk space that user can use on a particular volume. Directory quotas
are applied to all users and limit the amount of disk space that users
can use in a particular folder and its subfolders. Directory quotas were
introduced in Windows Server 2003 R2 with the new File Server Resource
Manager, and they are covered in detail in Chapter 20.

Enabling Quotas on a Disk

By default, disk quotas are disabled in Windows Server 2008. You can
enable disk quotas on any volume that has been assigned a drive letter.
To enable quotas on a volume, follow these steps:

1. In Windows Explorer, right-click a drive letter and open the properties of that drive.
   
2. Click the Quota tab, shown in Figure 19-23, and then click Show Quota Settings.
   
   
   Figure 19-23 The Quota tab of a drive's properties
3. Select the Enable Quota Management check box to enable quotas for the disk, as shown in Figure 19-24.
   
   
   Figure 19-24 The Quota Settings dialog box for a disk
4. To enable hard quotas that can't be exceeded, select the Deny Disk Space To Users Exceeding Quota Limit check box.
   
5. Set the limits and warning level, as shown in Figure 19-24. You can also enable logging on this page.
   
6. Click OK to enable the quotas. You'll be prompted one last time
   to confirm, as shown in Figure 19-25. Click OK and the quotas will be
   enabled.
   
   
   Figure 19-25 The Disk Quota confirmation message

Setting Per-User Quotas

You can set quota limits on individual users, or you can have limits
apply equally to all non-administrative users. Unfortunately, you can't
set limits on groups of users. And any users who already own files on
the disk will have their quotas initially disabled. New users will have
the default quotas for the disk applied as you would expect when they
first save a file on the disk.


To set the quotas for individual users, follow these steps:

1. In Windows Explorer, right-click a drive letter and open the properties of that drive.
   
2. Click the Quota tab, and then click Show Quota Settings to bring up the Quota Settings dialog box for that disk.
   
3. Click Quota Entries to open the Quota Entries dialog box for the disk, as shown in Figure 19-26.
   
   
   Figure 19-26 The Quota Entries dialog box for a disk
4. To modify the quota for a user already listed, select the user
   and then click Properties to open the quota settings for that user, as
   shown in Figure 19-27. Set the quota for the user and click OK to return
   to the Quota Entries dialog box.
   
   
   Figure 19-27 The Quota Settings dialog box for an individual user
5. To create a quota for a user who doesn't have one yet, and who
   needs a quota different from the default for the disk, click New Quota
   Entry.
   
6. Select the user or users to apply the new quota to, and click
   OK to bring up the Add New Quota Entry dialog box, as shown in Figure
   19-28.
   
   
   Figure 19-28 The Add New Quota Entry dialog box
7. Click OK to add the new entry and return to the Quota Entries
   dialog box. Close the Quota Entries dialog box, click OK in the Quota
   Settings dialog box, and then click OK in the Properties dialog box for
   the drive.
   
8. To manage quotas from the command line, you need to use
   Fsutil.exe. Even for a determined command-line type, it's pretty lame.
   Stick to the GUI, and use import and export whenever possible.

Importing and Exporting Quotas

Managing disk quotas is a potentially tedious job if you try to use
fine-grained control of individual quotas. The best solution is to use a
single, general quota that is correct for almost all users, and then do
only limited exceptions to that quota for very specialized cases. If
you do have complicated quotas, however, and you need to transfer them
to another server or another volume, you can export a set of quotas and
then import them to another volume.


To export the quotas on a volume, follow these steps:

1. Open the Quota Settings page for the volume you want to export the quotas from.
   
2. Click Quota Entries to open the Quota Entries dialog box.
   
3. Highlight the quotas you want to export.
   
4. Choose Export from the Quota menu. Type in a name and location for the export file and click Save.

To import a quota file to a volume, follow these steps:

1. Open the Quota Settings page for the volume you want to import the quotas to.
   
2. Click Quota Entries to open the Quota Entries dialog box.
   
3. Choose Import from the Quota menu. Type in a name and location for the import file and click Open.
   
4. If there are conflicting quotas, you'll be prompted to replace the existing quotas, as shown in Figure 19-29.
   
   
   Figure 19-29 Importing quotas can cause an existing quota to be replaced.
5. Choose to replace a quota by clicking Yes or to not keep the
   existing one by clicking No. You can have the action repeated for any
   further conflicts by selecting the Do This For All Quota Entries check
   box.

System restart cannot be completed while another software installation is in progress. Please allow the software installation to complete before attempting a system restart 0 System restart cannot be completed while another software installation is in progress. Please allow the software installation to complete before attempting a system restart

User gets an error prompt "A system restart cannot be completed while another software installation is in progress. Please allow the software installation to complete before attempting a system restart."

User gets an error prompt "A system restart cannot be completed while another software installation is in progress. Please allow the software installation to complete before attempting a system restart."

 

Cause:

Under very specific conditions, the persistent job counter is not decremented when a job is finished. The coordinating system prevents these client computers from being restarted because it believes that a job is still running based on the JobCounter value.

Solution:

1.     Stop the SMS Agent Host (CcmExec.exe) service on a System Center Configuration Manager 2007 SP1 client computer.

2.     Location the following registry subkey and change its value to 0:
HKEY_LOCAL_MACHINE\Software\Microsoft\Sms\Mobile Client\Reboot Management\JobCounter

3.     Start the SMS Agent Host (ccmExec.exe) service on the client computer.

Microsoft URL: http://support.microsoft.com/kb/970635/

Published By

S.G.Godwin Dinesh.MCA
Sr.System Administrator