Securing Windows Server 2008 in the Branch Office

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
8/13/2011 3:37:20 PM

Overview of Security for the Branch Office

The first component of the security policy and program used to implement security at the branch office is a definition of adequate physical security. Physical security is intended to keep intruders out and to keep the valuable information system assets in. Physical security is implemented in obvious things like solid walls, fences, doors and locks, guards and guard dogs, and internal security zones, like a secure server room with card swipes in and out, designed to provide differing levels of security as users enter the different security zones. Physical security is also implemented in more technical components, like the use of strong passwords, smart cards, and biometrics.

Next, acceptable use policies should be created to include any device or system in the facility and in any device owned by the enterprise that gets issued to the worker. One of the most effective security measures that can be implemented, after the security policy, the security program, and the acceptable use policies, is security awareness training for all users. This should cover facility safety training and an overview of the security policy. Employees should understand that they have specific responsibilities related to the security program and that they must know what the rules of the policy are. They must further understand that violation of any security policy could be grounds for termination. Employees should be constantly reminded and aware of the security concerns of the organization. For example, this can be accomplished through posters or a column in the monthly newsletter citing recent violations and threats, as well as through feedback from IT and through management, when users are identified to be in violation of acceptable use of the computers and information systems.

Security awareness training should be performed at least annually for all employees and should be provided at a higher level and more often as the role of the user rises in the organizational structure in the enterprise. Management personnel must understand their responsibility to know the relevant security policies, as well as their roles as the enforcers of the security policy in their departments. Middle management must provide enforcement at the lower levels of management, and so on.

When employees know what the acceptable use rules are and understand their responsibilities, the security structure should include auditing and monitoring of the facility and as much of the environment as is legal. It should be explained that this monitoring is for the safety and security of the employees, as well as for the assets of the enterprise.

Note: A warning about employee monitoring

The laws in the United States on employee monitoring vary greatly from state to state and even county to county. Typically, the employee must be aware of, and agree to, the monitoring. Furthermore, the monitoring cannot target specific individuals, which would amount to discrimination. The monitoring should be performed routinely and randomly.

Always consult the local legal department for documented guidelines on how, what, and whom can be monitored, and do not exceed these guidelines.

You will, of course, enable a comprehensive audit policy on the information systems. You might want to monitor by using CCTV cameras and recording devices, and you might want to record network and Internet usage for any and all employees. You might want to have access to monitor the display on the computer monitor (these can indeed be shadowed by the administration) and be able to search any hard disk drive on the corporate network. You should monitor employees’ company e-mail and voicemail. You should monitor the employees any time they are on the company premises, any time they are using company-owned resources (such as cell phones and portable computers), and any time they are acting as a representative of the organization—again, only within the limits of the law. Don’t forget that in most cases the organization is legally responsible, and therefore liable, for anything inappropriate that an employee does while on company business or while using any of the organization’s devices.

Recording all of this information is beneficial, but it is useless unless someone is specifically responsible for the review of the audit logs, the intrusion detection system (IDS) and intrusion prevention system (IPS) logs, the videotapes, the call logs, the firewall logs, and so on. This is the difficult part. Because the reviewers are looking at the actual map of attacks, exploits, violations, and events that occurred on the system, they must decipher an understanding of what these many logs and events actually say. The responsible person must identify violations, attempted violations, and unexpected vulnerabilities in the environment and develop proposals on the implementation of new and appropriate countermeasures to mitigate the risks and defend against these attacks in the future.

Furthermore, in many cases, these logs must be tightly secured, with their integrity protected and provable, and retained in archives for several years to satisfy legal and regulatory compliance requirements.

Securing Windows Server 2008 in the Branch Office

Now that the foundation of security is in place, including the security policies, employee safety, physical security, awareness training, and monitoring, the next security objective is the electronic security of the information systems. The threats to information systems that are covered in this section include threats from willful and malicious hacker attack, from malware, from willful or accidental modification of data or system configuration, and from privilege misuse.

Security Overview for the Information System in the Branch Office

Each branch office implementation must be individually and carefully designed, implemented, and maintained. There are, however, several core security components that virtually every branch office network installation should include.

Infrastructure Firewalls

The branch office network should be isolated from external networks, including the network at HQ, through one or more firewalls. They can be placed in series (one behind the other) to construct a perimeter network (also known as DMZ, demilitarized zone, and screened subnet) for public resources or resources shared with HQ. They can be placed in parallel and through different Internet service providers (ISPs) to provide redundancy for the WAN link connections to the Internet or to HQ.

Host-Based Firewalls

In addition to the network-based firewalls, Windows Server 2003, Windows XP, Windows Vista, and Windows Server 2008 all have a built-in, host-based firewall (often called a personal firewall). In general, these host-based firewalls should all be enabled and properly configured to allow only the minimum required traffic into and out of the Windows-based computers. Windows Vista and Windows Server 2008 provide for advanced configuration in the host-based Windows Firewall with Advanced Security.

The Intrusion Detection System/Intrusion Protection System

Another infrastructure device that you should consider on the branch office network is the Intrusion Detection System/Intrusion Protection System (IDS/IPS). These are third-party devices (or systems). The IDS monitors network traffic, logs data about the traffic, analyzes the traffic based on signatures and anomalies, recognizes potential attacks, and alerts the administrative staff to the perceived attack. The IPS does all that, but it also has the capability to react to the perceived attack. This reaction can be an adjustment to the rule base on one or more firewalls to reject the attacker’s frames, or the transmission of TCP NACK to the victim, or the transmission of deauthentication frames to an 802.1x port-based authentication switch to disconnect the victim from the attacker.

Server Hardening

The next routine security target on all computer systems is server hardening, or creating the bastion host. This reduces the attack surface of the computer by reducing the number of targets available on the system to a hacker. In general, server hardening includes the following:

  • Stopping and disabling all unnecessary services and applications

  • Renaming the Administrator account

  • Creating a new, useless, and disabled user account named Administrator and securing it with an impossible password

  • Removing or disabling all unnecessary user accounts

  • Delegating remaining user accounts based on the principle of least privilege

  • Requiring strong authentication of users

  • Performing regular firmware, operating system, and application updates

  • Installing, running, and regularly updating antivirus and anti-spyware applications

  • Regularly documenting and then reconfirming the system configuration

  • Implementing routine auditing on logons, network connections, object access, and system configuration changes

This is the basic hardened server configuration that should be implemented on every computer in the enterprise. However, for critical or exposed servers, you should implement additional lockdowns. They include the following:

  • Deleting all nonessential executables (binaries) from the computer

  • Deleting all administration tools

  • Configuring a GPO to disable and further restrict unused services

  • Creating scripts to lock down services and schedule them to run each hour

  • Implementing a routine or process to detect changes to the system files or system configuration (you can use the Microsoft System File Checker [SFC.exe] for this purpose. A popular third-party tool named Tripwire is available to validate the integrity of system files, as well.)

  • Monitoring system activity and network traffic to and from the hardened server

  • Implementing more detailed auditing on logons, network connections, object access, and system configuration changes

Securing Windows Server 2008 in the Branch Office

Windows Server 2008 has introduced several significant enhancements to improve security in installations like the branch office. The most important new additions are the following:

  • The Server Core server

  • The read-only domain controller (RODC)

  • The Password Settings Object (PSO)

  • Network Access Protection

  • Administrator Role Separation

The Read-Only Domain Controller

A new security-related feature in Windows Server 2008 is the RODC. It is designed for implementation in environments where:

  • There is a need for local access to Active Directory by users, computers, applications, or other entities.

  • The physical security of the server cannot be guaranteed.

  • The server might be exposed to a hazardous network environment, such as an extranet.

  • There are relatively few users.

  • WAN link connectivity to the main network might be unreliable.

  • Local technical support skills might be limited.

As you review that list, you will undoubtedly realize that it sounds like a branch office environment. The RODC differs from the full DC in the following ways. The RODC:

  • Holds a read-only copy of the Active Directory database.

  • Participates in only one-way replication of all replication partitions, including domain data from a Windows Server 2008 DC.

  • Participates in only one-way replication of schema, configuration, and application directory partitions, and the global catalog from a Windows Server 2003 DC but not the domain partition.

  • Does not receive user or computer credentials (passwords) from Active Directory, by default.

  • Can cache only selected user and computer credentials for accounts specified in a Password Replication Policy.

  • Supports the removal of specified sensitive attributes from replication through the RODC filtered attribute set.

  • Supports Administrator Role Separation.

  • Supports a read-only instance of the DNS zones.

RODC Disadvantages

Because of the read-only nature of the RODC, it cannot be used as an operations master or a replication bridgehead server. In addition, if Active Directory–aware applications need to write data to Active Directory, the RODC cannot accept those write commands and the application’s process will fail. Microsoft Exchange Server is an example of this type of application. An Active Directory write process fails if the request is sent to an RODC. Active Directory–aware applications should be tested with the RODC prior to deployment into production.

The RODC might fail to authenticate smart card logons by default. For any DC to be able to authenticate smart card logons, the DC must receive a domain controller X.509 digital certificate from a trusted certification authority. These digital certificates are typically distributed to the DCs through certificate autoenrollment. The permissions on the certificate template must be modified to allow the RODC to receive this certificate.

The RODC does not advertise properly as a time source, causing the clocks on the branch office client computers to become desynchronized. The simple solution is to configure a Windows Server 2008 full DC server as the PDC emulator operations master for the domain, making it the time master for the domain. Another solution is to manually configure a time master for the domain.

Installing an RODC

You need to take a few steps before you can install the first RODC in a domain:

  1. Ensure that the forest functional level is Windows Server 2003 or higher. Remember that this means you must purge the forest of any Windows NT Server 4.0 and Windows 2000 Server DCs.

  2. Run ADPrep/RODCPrep. This can only be done on the Schema Operations master for the forest and only by a member of the Enterprise Admins group. This step is not required if this is a new Windows Server 2008 forest. Copy the contents of the \sources\adprep folder to the schema master DC, and execute the command from there.

  3. Install a Windows Server 2008 DC into the domain. This DC is the replication source for the RODC. The Windows Server 2008 DC must hold the PDC emulator operations master role and be located in the site nearest the site of the RODC, based on site link cost.

Then you can install the RODC on a Windows Server 2008 server. You can install the RODC on a Windows Server 2008 full installation server or on a Windows Server 2008 Server Core installation server. Installing the RODC on the Server Core server provides the greatest level of security because of the hardened server nature of the Server Core server.

Delegated Installation of the RODC

The RODC computer object can be created in, or moved to, the DC OU during the installation of the RODC, but this will require membership in the Domain Admins group in the domain for the installer. However, this level of privilege is often not desirable for users in the remote office.

Because the RODC is often located in a remote office with a nondomain administrator user as the installer, it is possible to pre-create the RODC account in the Domain Controllers OU in Active Directory Users and Computers and delegate authority to the remote, nondomain administrator installer who completes the DCPromo installation. Furthermore, you can specify details about the DCPromo installation that get stored on this unoccupied domain controller account object. These details get pushed down to the remote RODC during the DCPromo installation.

In Active Directory Users And Computers, on the Domain Controllers OU, right-click and select the Pre-Create Read-Only Domain Controller Account option, as shown in Figure 1. You now see the Active Directory Domain Services Installation Wizard.

Figure 1. The delegated RODC installation

To see all configurable options for the RODC, on the Welcome page, select the Use Advanced Mode Installation check box. After a few standard DCPromo pages, such as the Network Credentials page, you are prompted to define information, such as the necessary credentials to pre-create the domain controller account, computer name, site location, and whether you want to configure the RODC to host services such as DNS or the global catalog. You can next specify the Password Replication Policy for the RODC server, as shown in Figure 2.

Figure 2. Specifying the Password Replication Policy for the RODC installation

This policy defines the list of passwords that can be replicated to, and cached on, the RODC. This Password Replication Policy will be explained in more detail later in this lesson. The Active Directory Domain Services Installation Wizard next prompts you to specify which user or group of users are delegated the authority to run the DCPromo process on the Windows Server 2008 server in the remote office, as shown in Figure 3. The delegated users do not require any additional privileges to complete the installation.

Figure 3. Specifying the nonadministrator installer of the remote RODC

The recommendation for granting privilege, including the privilege to install an RODC, as always, is to follow A-G-DL-P. Place user accounts into global groups, place global groups into domain local groups, and then grant the necessary privileges to the domain local group. The Summary dialog box has an Export button to generate an answer file for use in other similar unattended installations.

Installing the RODC from Customized Media

As you probably recall from Windows Server 2003, the DCPromo utility could be executed using the /ADV switch. This allowed the remote DC to acquire the Active Directory database (NTDS.dit) from a system state data backup copy of a DC in the same domain. This feature has been replaced in Windows Server 2008 with what is called Install From Media (IFM). By using the NTDSUTIL.exe utility with the IFM subcommand, you can create a copy of the NTDS.dit database and remove “cached secrets”—that is, passwords that you do not want to cache on the RODC server.

The RODC installation methods that can use the custom IFM media with passwords removed from the Active Directory database include the following:

  • The Active Directory Installation Wizard (DCPromo.exe) where the media can be specified

  • From the command line using DCPromo/ReplicationSourcePath

  • Within an Answer file

The RODC Authentication Process

In Windows Server 2008, the authentication processes have been changed in environments like a branch office where the only DC is an RODC. When a member computer boots up or when a user attempts to log on to a domain account, the request is sent to the local DC—in this case, it is an RODC. The RODC does not cache user or computer credentials by default. The RODC, acting as a relay agent, will then refer the authentication request across the WAN link to a Windows Server 2008 full (writable) DC in the nearest site. This can be slow and will fail the authentication process if the WAN link is down.

To improve performance and reliability, an administrator can create a Password Replication Policy that will replicate the passwords of the users and computers in the remote branch office to the branch office RODC. Now when a member computer boots up or when a user attempts to log on to a domain account, the local RODC can complete the authentication process within the local branch office. A different Password Replication Policy can be created for each RODC.

If a member computer boots up or a user attempts to log on to a domain account and the local RODC does not have its credentials cached, after the authentication process completes through the referral process, the RODC will request that the writable DC replicate the credentials to the RODC for caching. If the account (user or computer) is on the Allowed list of the Password Replication Policy for that RODC, the credentials are replicated from the writable DC to the database of the RODC in the branch office.

If the account is not on the Allowed List of the Password Replication Policy for that RODC, the credentials are not replicated from the writable DC to the RODC, and the authentication process will need to be completed over the WAN link through the referral process every time.

The Password Replication Policy maintains four lists. They are:

  • Allowed List These passwords (secrets or credentials) can be replicated to the RODC.

  • Denied List These passwords (secrets or credentials) cannot be replicated to the RODC.

  • Revealed List A list of accounts whose passwords are cached on RODCs. This list can be used to reset passwords of accounts on RODC servers that become compromised.

  • Authenticated List A list of accounts that have been successfully authenticated against the RODC.

You can view these lists in Active Directory Users and Computers by displaying the properties of the RODC server’s computer object. In the Password Replication Policy tab, you can see the allowed and denied entities by examining the Setting column, as shown in Figure 4.

Figure 4. Accessing the Allowed and Denied Lists on the RODC

Click the Advanced button to access the Revealed and Authenticated Lists, as shown in Figure 5.

Figure 5. Accessing the Revealed and Authenticated Lists on the RODC

Replication Concerns with the RODC

As stated previously, the RODC can receive domain replication data only from a Windows Server 2008 full (writable) DC. The site with the RODC must be connected to a site with a Windows Server 2008 full (writable) DC in the same domain, by a site link with the lowest cost. If the nearest site (again, based on site link cost) does not contain a Windows Server 2008 full (writable) DC in the same domain, domain data replication to the RODC will fail.

The RODC can receive all other partitions of replication from a Windows Server 2008 DC or a Windows Server 2003 DC.

Automatic Site Coverage

Sites are defined in Active Directory by mapping IP subnets to specific sites. Active Directory clients authenticate against and otherwise access DCs in their local site, based on their IP addresses. To ensure that all Active Directory clients are able to identify the appropriate local DC, DNS SRV records are created for DCs and mapped to each site within the DNS zone for the domain.

Because it is possible to create a site without placing a domain controller in the site, Windows 2000 Server, Windows Server 2003, and Windows Server 2008 perform a service called automatic site coverage. If a site is recognized to be without a DC, a DC in the nearest site, based on site link cost, registers a service location (SRV) record for the remote site. This allows the Active Directory clients in the remote site without a local DC to connect to the nearest DC to their site.

However, Windows 2000 Server and Windows Server 2003 do not recognize a Windows Server 2008 RODC and might register a SRV record for a remote site, with only an RODC in it. This is a problem. In DNS for the branch office site there is a SRV record for the RODC that is actually in the branch office site and a SRV record for a Windows 2000 Server DC or a Windows Server 2003 DC in a site remote from the branch office. With DNS round robin (enabled by default), 50 percent of the time Active Directory clients in the branch office site will commute the WAN link to access Active Directory when they have their own RODC locally. This causes increased and unnecessary traffic on the WAN link, degrades performance, and can cause Active Directory–related failures for clients in the branch office site if the WAN link is down.

At the time of this writing, Microsoft recommends using one of five adjustments to resolve this problem:

  • Wait for a hotfix from Microsoft.

  • Use only Windows Server 2008 DCs in the site nearest to the RODC site.

  • Disable automatic site coverage on the Windows 2000 Server DCs and the Windows Server 2003 DCs.

  • Adjust the weight of the Windows Server 2003 DC SRV records (this is only a partial solution).

  • Use a GPO to adjust the weight of the Windows Server 2003 DC SRV records (this is only a partial solution).

RODC Compromise

The main reason to use the RODC is the increased threat of compromise of the DC in an unsecure environment, either by physical theft or access of the system or electronic attack. If the RODC is stolen or becomes otherwise compromised and the hacker cracks into the Active Directory database, the hacker has access to only a few account passwords, so the amount of accounts potentially compromised is reduced. By using the Revealed List for the RODC in Active Directory Users and Computers, you can quickly reset the potentially compromised passwords.

Because the RODC cannot replicate to other DCs, there is no risk of a hacker modifying anything in Active Directory, such as permissions and group membership, and then poisoning the legitimate Active Directory through replication.

If your RODC is stolen, you can easily delete the RODC computer object in Active Directory Users and Computers without a successful DCPromo to remove the DC from Active Directory and without using the NTDSUTIL MetadataCleanup command. (Using the NTDSUTIL MetadataCleanup command to remove Active Directory objects leaves broken links from processes that refer to the now removed object. These broken links will generate numerous errors about the missing object in event logs of DCs for the life of the domain.) To delete the RODC computer object, in Active Directory Users And Computers, right-click the RODC computer object in the Domain Controllers OU, and select Delete. Click OK to close the Warning message dialog box. You can then export a list of all accounts that were cached on the RODC and force the resetting of user and computer passwords for all accounts that were cached on the RODC, as shown in Figure 6.

Figure 6. Deleting a stolen RODC from Active Directory Users and Computers

To summarize, a Windows Server 2008 domain controller in the branch office will maximize performance by having a local copy of all passwords, accepting Active Directory changes, and performing two-way replication. But it also maximizes the amount of sensitive data loss and the risk of poisoning the legitimate Active Directory in the case of compromise.

A Windows Server 2008 RODC in the branch office will support most Active Directory requirements in the branch office while minimizing the amount of sensitive data loss and the risk of poisoning the legitimate Active Directory in the case of compromise. The more accounts you cache, the better the performance but the greater the risk of exposure. The fewer accounts you cache, the poorer the performance but the less the risk of exposure.

Installing the RODC on a Windows Server 2008 Server Core server in the branch office provides the greatest level of security in the branch office by reducing the attack surface of the server and minimizing the amount of sensitive data loss and the risk of poisoning the legitimate Active Directory in the case of compromise.

The RODC supports delegated installation, as well as Administrator Role Separation for increased security.

The Password Settings Object

New to Microsoft Windows Server 2008 is the ability to define different password and account lockout policies to users in the domain. This support for different policies for different users is called fine-grained password policies. In earlier versions of Windows, only one password and account lockout policy could be effective for all users in the domain. It is a common concern that different users in the domain, like the users in a branch office, require different strengths of passwords and more or less strict account lockout policies. These differing password policies are defined in Password Settings Objects (PSOs) and are applied to users and (preferably) groups of users. PSOs cannot be applied to computer objects or to OUs.

To utilize fine-grained password policies in the branch office, the domain functional level must be set to Windows Server 2008. This requires that all DCs in the domain run Windows Server 2008. Next, create one or more global security groups, one for each different PSO required in the branch office, and populate the group(s) with the appropriate users. 

Using fine-grained password policies, you can configure values, including the following:

  • Maximum Password Age

  • Minimum Password Age

  • Minimum Password Length

  • Password History

  • Password Complexity

  • Reversible Encryption Enabled

  • Account Lockout Threshold

  • Account Lockout Window

  • Account Lockout Duration

  • Users or global security groups to which the PSO applies

If you don’t like ADSI Edit, you can use LDIFDE. LDIFDE uses a script to configure the new PSO. Save the following script to an ASCII text file and apply an .ldf file extension. Adjust the parameters as desired. For example, you will need to replace the domain name specified in the “dn:” line with your domain name.

dn: CN=BoPSO, CN=Password Settings
changetype: add
objectClass: msDS-PasswordSettings

The time values are calculated using the I8 format. The I8 format breaks the time units into negative 100 nanoseconds (billionths of a second), so all forward-looking time values must be negative. To convert time into I8 values:

  • Multiply minutes by -6,000,000,000.

  • Multiply hours by -36,000,000,000.

  • Multiply days by -864,000,000,000.

After you create the PSO, you can adjust the users and groups to which it is applied by using Active Directory Users and Computers. Complete the following steps:

Under the View menu item, select Advanced Features.

Expand the Active Directory Users And Computers tree to <Domain Name>, System, and then select the Password Settings Container.

In the right pane, right-click the PSO and choose Properties.

In the Attribute Editor tab, select the msDS-PsoAppliesTo attribute and click Edit.

Add the distinguished name of the user or global security group to which you want to apply the PSO or remove the desired entry.

Fine-grained password policies allow administrators to define unique password and account lockout policies for users and global security groups in a domain. They are well-suited for application to users in the branch office environment, which commonly requires a different level of security.

Security for Data in Storage

Another area of security for the nonsecure branch office that you should address is security for data in storage. If a computer is stolen from a branch office, the thief could crack user accounts on the system and access data stored locally on the hard disk drives. If the thief removes the hard disk drives from the original computer and mounts them in another computer where he or she is the administrator, the thief can access all the content. Windows Server 2008 provides two ways to secure this stored data:

  • The Encrypting File System (EFS)

  • BitLocker

The Encrypting File System (EFS)

EFS was introduced in Windows 2000. It provides encryption for data files and folders only. It requires that the underlying volume (partition) be formatted with NT file system (NTFS). It uses self-generated X.509 digital certificates associated with the user account to secure encryption keys for the encrypted content. Ultimately, one accesses the decryption key by knowing the user’s password. If the hacker can crack the password, the hacker can decrypt all of the user’s EFS protected content.

By default, the local administrator (standalone) or the domain administrator (domain member) is the EFS recovery agent and can decrypt any EFS-secured content. EFS cannot be applied to system or AD DS–related files. All other users who attempt to access another user’s EFS content receive an Access Denied error, even if proper permissions are granted.


BitLocker was introduced in Windows Vista and is available in Windows Server 2008. A specific partition structure must be configured prior to the installation of the operating system in order for BitLocker to be available for implementation on a system. BitLocker encrypts the entire volume and can be applied to system, boot, and data volumes. BitLocker encryption remains intact even if the hard disk drive is installed in another computer and is mounted by another operating system.

Note: BitLocker

Use BitLocker if you need to secure the NTDS.dit database.

BitLocker is based on the Trusted Platform Module (TPM), currently version 1.2. TPM is a microchip that holds the encryption/decryption key and a piece of code in the BIOS used to perform the encryption/decryption process on the specified disk volumes. You can also implement BitLocker on systems without TPM support by storing the encryption/decryption key on a USB thumb drive.

In either case, a recovery key or recovery password, or both, should be exported to external media in case the original encryption/decryption key(s) are lost. By default, no recovery information is backed up. The recovery password is a 48-character numeric value that can be typed into the BitLocker Recovery Console. The recovery key is stored on a USB thumb drive and can be accessed by the BitLocker Recovery Console. In addition, you can generate and store the recovery passwords in AD DS by means of a GPO. The recovery key and recovery password should be securely stored separate from the computer.

Securing the Branch Office with Network Access Protection

In Windows Server 2008, administrators can use Network Access Protection (NAP) to ensure that remote, local, and branch office clients meet minimum security and configuration compliance requirements for secure connections to branch office and HQ networks. NAP checks the client’s health status regarding the state of its firewall, updates, antivirus protection, and anti-spyware protection for the Windows XP SP3, Windows Vista, and Windows Server 2008 operating systems.

Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us