Tag Archives: 70-742

70-742 Additional Notes – Software Deployment Using Group Policy

Microsoft Windows Server, , , , ,

70-742

Group Policy is one of your many options for automating the deployment of software in your Enterprise and is a huge topic for the 70-742 exam. You can use such policy to deploy applications to computer or users. Be sure to audit your Group Policy settings to ensure that you are only deploying the application once to a target user or system. Obviously, whenever possible, consider having the policy for distribution as high up in the directory structure as possible.

Windows Installer packages make software distribution in in this manner possible. You assign or publish the software using Software Installation in Group Policy. This is only possible if your file type fits one of the following categories:

  • Native Windows Installer package (.msi)
    • Provide the best overall deployment experience
    • Take full advantage of the Windows Installer
    • Allows for components to install on demand and also permits applications to self heal
    • You can enact modifications with a .mst file
    • You can enact software patches with a .msp file
  • Repackaged application (.msi) files
    • You can repackage an application that does not have a native Windows Installer Package
    • Keep in mind that the installation occurs as a single component; unlike what is possible with native Windows Installer Packages
  • An application file (.zap) – this installs the application by using its original setup.exe program; note that these files can only be published, not assigned
    • Define the setup.exe or install.exe into a .zap file in order to deploy them
    • A .zap file is a text file that contains information on how to publish the application
    • This approach is less flexible than native Windows Installer packages – for example, you would not be able to override the need for administrative privileges for installation

    InformIT (Pearson Education)

70-742 Additional Notes – Standalone Certificate Authorities

Microsoft Windows Server, , , ,

70-742

Overview

Stand-alone certification authorities (CAs) can issue certificates for purposes such as:

  • Digital signatures
  • Secure e-mail by using S/MIME (Secure Multipurpose Internet Mail Extensions)
  • Authentication to a secure Web server by using Secure Sockets Layer (SSL) or Transport Layer Security (TLS)

Characteristics

  • Unlike an enterprise CA, a stand-alone CA does not require the use of Active Directory Domain Services (AD DS). Even if you are using AD DS, stand-alone CAs can be used as offline trusted root CAs in a CA hierarchy or to issue certificates to clients over an extranet or the Internet.
  • When users submit a certificate request to a stand-alone CA, they must provide their identifying information and specify the type of certificate they need. (This does not need to be done when submitting a request to an enterprise CA because the enterprise user’s information is already in AD DS and the certificate type is described by a certificate template). The authentication information for requests is obtained from the local computer’s Security Accounts Manager database.
  • By default, all certificate requests sent to the stand-alone CA are set to pending until the administrator of the stand-alone CA verifies the submitted information and approves the request. The administrator has to perform these tasks because the certificate requester’s credentials are not verified by the stand-alone CA.
  • Certificate templates are not used.
  • The administrator has to explicitly distribute the stand-alone CA’s certificate to the domain user’s trusted root store, or users must perform that task themselves.
  • If a cryptographic provider supporting elliptic curve cryptography (ECC) is used, a stand-alone CA will honor every key usage for the ECC key.

When a stand-alone CA uses AD DS, the CA has these additional features:

  • If a member of the Domain Admins group or an administrator with Write access to a domain controller installs a stand-alone root CA, it is automatically added to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. For this reason, if you install a stand-alone root CA in an Active Directory domain, you should not change the default action of the CA upon receiving certificate requests (which marks requests as pending). Otherwise, you will have a trusted root CA that automatically issues certificates without verifying the identity of the certificate requester.
  • If a stand-alone CA is installed by a member of the Domain Admins group of the parent domain in the enterprise, or by an administrator with Write access to AD DS, then the stand-alone CA will publish its CA certificate and the certificate revocation list (CRL) to AD DS.