Firstly we will install the ADCS role with Server Manager:

Select “Role-based installation or Feature-based installation” and click next. We now need to select the server on which you will install the role, under Windows 8 you can manage a remote server

Choose the Active Directory Certificate Services role:

Skip the Features screen, then under the role services screen, select only Certification Authority:

On the next screen we start the role installation. Once it is done, open a Powershell session on the server on which the role is installed and launch the following command:

Get-Module –ListAvailable

We notice that a new module called CertificateServicesCmdlets shows up. We can list the cmdlets available in that module with the command:

(get-module CertificateServicesCmdlets).exportedcommands

Here are the cmdlets:

Get-AdcsCertificationAuthorityConfigurationDefaults
Get-AdcsConfigurationState
Get-AdcsEnrollmentPolicyWebServiceConfigurationDefaults
Get-AdcsEnrollmentWebServiceConfigurationDefaults
Get-AdcsNetworkDeviceEnrollmentConfigurationDefaults
Get-SSLCertificates
Import-AdcsCertificationAuthorityCACertificatePfx
Install-AdcsCertificationAuthority
Install-AdcsEnrollmentPolicyWebService
Install-AdcsEnrollmentWebService
Install-AdcsNetworkDeviceEnrollmentService
Install-AdcsOnlineResponder
Install-AdcsWebEnrollment
Uninstall-AdcsCertificationAuthority
Uninstall-AdcsEnrollmentPolicyWebService
Uninstall-AdcsEnrollmentWebService
Uninstall-AdcsNetworkDeviceEnrollmentService
Uninstall-AdcsOnlineResponder
Uninstall-AdcsWebEnrollment

We will use the Install-AdcsCertificationAuthority in order to configure our Enterprise rootCA server. The script setupCA.vbs inspired us to launch the following command:

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA -CACommonName LDAP389-CA -KeyLength 4096 -HashAlgorithmName SHA256 -CryptoProviderName "RSA#Microsoft Software Key Storage Provider"

Here we go, the Enterprise rootCA server is ready to use. We launch the Certification Authority console in order to check that the configuration matches the parameters we set up with Powershell:

Under Windows 8 you can configure your PKI with Powershell, but maybe not yet get rid of the excellent PS PKI module developed by the Powershell Crypto Guy, time will tell…

N.B.: As it is a Developer Preview the cmdlets and installation procedure might change in the future.

Once installation was completed, I launched the following Powershell command:

(get-module ActiveDirectory).exportedcommands

In order to list all the Cmdlets available for the Active Directory module. We notice, among others, new Cmdlets for managing Active Directory replication topology:

Get-ADReplicationAttributeMetadata

Get-ADReplicationConnection

Get-ADReplicationFailure

Get-ADReplicationPartnerMetadata

Get-ADReplicationQueueOperation

Get-ADReplicationSite

Get-ADReplicationSiteLink

Get-ADReplicationSiteLinkBridge

Get-ADReplicationSubnet

Get-ADReplicationUpToDatenessVectorTable

New-ADReplicationSite

New-ADReplicationSiteLink

New-ADReplicationSiteLinkBridge

New-ADReplicationSubnet

Remove-ADReplicationSite

Remove-ADReplicationSiteLink

Remove-ADReplicationSiteLinkBridge

Remove-ADReplicationSubnet

Set-ADReplicationConnection

Set-ADReplicationSite

Set-ADReplicationSiteLink

Set-ADReplicationSiteLinkBridge

Set-ADReplicationSubnet

The ldap389.local domain replication topology is as follows:

Firstly we will list the Active Directory sites with the command:

Get-ADReplicationSite -filter {cn -like "*"}

There are two sites in the domain: HQ-LDAP389 and BRANCH-LDAP389. We also retrieve the ISTG of each site.

Secondly we list the Active Directory site links using the following command:

Get-ADReplicationSiteLink -filter {cn -like "*"}

The only site link is the default one: DEFAULTIPSITELINK. It is configured to launch a replication every 15 minutes between both sites.

Finally we will list every Active Directory replication connection with the command:

Get-ADReplicationConnection -filter {cn -like "*"}

There are two connections: The first one to replicate from ldap389-pdce to ldap389-dc2, the second one to replicate in the opposite direction.
I want to reassure you: The repadmin command is not deprecated under Windows 8 Developer Preview, unlike the dcpromo which is replaced by the ADDSDeployment Powershell module.

N.B.: As it is a Developer Preview those cmdlets might change in the future. But this post shows you that you will be able to manage ADDS replication with Powershell

In order to perform a connection on each TMG server we invoke the ConnectToConfigurationStorageServer method. Then we use the FPCPolicyRules collection in order to browse the different firewall rules. For each TMG server is displayed:

• The rule name.
• Wether the rule is enabled.
• Action: Allow traffic (0), deny traffic (1).

Each firewall rule is exported in the current directory in a file named %TMGSERRVERNAME%_%RULENAME%.xml. In order to export the configuration in XML format we invoke the FPC.ExportToFile method:

$oFPC = New-Object -comObject FPC.root
$cArrays = $oFPC.Arrays
Foreach ($oArray in $cArrays){
    $policyrules = $oArray.ArrayPolicy.policyrules
    foreach ($policyrule in $policyrules){
        $policyrule | select name,enabled,action
        $szOutFilePath = 'C:\' + $policyrule.name + '.xml'
        #See options for $iOptionalData at http://msdn.microsoft.com/en-us/library/aa490382.aspx
        $iOptionalData =  0x00000001 -bor 0x00000002 -bor 0x00000004 -bor 0x00000008
        $szPassword = "12345678"
        $szComment = ""
        $policyrule.ExportToFile($szOutFilePath, $iOptionalData, $szPassword, $szComment)
    }
 
}

Just click on the link below to download the full script:

Change the following default values:

• $servers: TMG server names.
• $iOptionalData: Export type (Radius data…) See this link for more details.
• $szPassword: Password used to encrypt confidential data (e.g. Radius data…)

Get-OwaVirtualDirectory | ft server,InternalURL,externalURL

In our example the internal URL is mail.internal.ldap389.info, the external URL is mail.ldap389.info. We want to ensure a secure SSL connection from the client to the OWA Website: To achieve that a SAN certificate issued by our enterprise PKI and including both URLs is installed on each member of the CAS array.

The network traffic of the computers located in your internal network, accessing the mail.internal.ldap389.info internal URL, is balanced across the CAS servers with a HLB device (represented by green arrows on the below diagram).

The clients connecting from the internet via the mail.ldap389.info internal URL first contact the TMG array, the traffic is balanced across the TMG server’s external NICs with a HLB device, those IPs are located in the public DMZ. The network traffic of the clients accessing your OWA from the internet is represented by red arrows on the below diagram and detailed in the next paragraphs:

I suggest you purchase a certificate from an external certificate authority and set it up on the TMG’s OWA web listener, by using this kind of certificate the computers which are not members of the internal.ldap389.info domain will perform an SSL connection with the TMG without any warning displayed on their web browser. If you use a certificate issued by your enterprise PKI, the certificate of the enterprise root CA will not be installed on the Trusted Root Certification Authorities store on the computers which are not members of your domain. For those computers you will get this kind of warning when connecting to the Outlook Web Access:

Communication is also secured with SSL between the TMG’s internal NICs (located in the “private DMZ”) and the CAS servers. In order to perform a secure communication by using the SAN enterprise certificate installed on the CAS servers, you have to install the certificate of the enterprise root CA as a trusted root CA certificate on your TMG servers.

TMG presents an HTML Form in which the user enters a user name and password, which TMG can then authenticate against Active Directory over LDAP secure protocol. LDAPs connection is performed on a Windows 2008R2 Core RODC which is a member of your internal network domain (DNS name rodc.internal.ldap389.info). You can configure more than one RODC in the LDAP Server Set in order to provide redundancy. You can cache credentials on the RODCs for users using the OWA from the internet, in that case you need to configure one AD site per RODC. Your TMG OWA listener will be set up as below:

In order to perform an LDAP over SSL connection with your internal RODC, the TMG must resolve the rodc.internal.ldap389.info name by using a host file. In the same host file, the mail.ldap389.info name points to the HLB which balances the traffic across the CAS servers (see host file on the diagram).

If you want to get all the benefits of a TMG Enterprise array, including the EMS replication, it needs to be member of a domain (dmz.local). I suggest you read this document on how to set up a domain in a DMZ. In our case there is neither trust relationship nor DNS forwarders between the two domains dmz.local and internal.ldap389.info (that is why we use host files). We only allow SSL connections between the private DMZ network and the internal network.

Securing your dmz.local domain is very important because it is located close to the internet, here are a few leads on how to secure it: The domain controllers should be located in a dedicated subnet in your private DMZ. TMG servers only authenticate against Windows 2008R2 RODCs, they should only communicate with a RWDC on the DNS TCP 53 port, in order to allow DNS update (see How does the client DNS update referral mechanism work?). In order to join a TMG server through a RODC perform the steps described in this article. You can also set up administrator role separation on the RODCs and deny password caching for domain administrators. Finally, you can set up the CachedLogonCounts value to 0 on the TMG servers, but you will not able log on with a domain account if no domain controller is available. In that configuration your TMG array is member of a secured domain and you can enjoy all the features of the enterprise version.

The purpose of this Powershell script is to make an inventory of all the mobile devices accessing your Exchange mail system. First we will retrieve BlackBerry devices information by querying the BES SQL configuration database, then the other devices using the ActiveSync protocol by querying the Active Directory.

BlackBerry Inventory:

Your BackBerry system configuration is stored in the BESMGMT SQL database, among other things you will find information about the Blackberry devices connecting to your mail system. We will query three tables in that database:

• UserConfig: Contains among others the user’s Email address (MailboxSMTPAddr value).
• SyncDeviceMgmtSummary: Blackberry model and OS version (ModelName and AppsVer).
• UserStats: Time the last message was received by the BlackBerry (LastFwdTime).

If you browse the database with SQL Management Studio you can see all that information:

You just need to use Powershell to connect to the SQL database and retrieve those values for each user. The primary key between the three tables is the ID value. We will filter only the users who received an Email during the last 60 days (LastFwdTime).

$days = 60
$dbServer = "SQLBES-SRV"
$db = "BESMgmt"
 
#If you use SA account to connect database, change pwd=XXXXXX!, or use Windows Authentication, see below
$connString = "Server=$dbServer;Database=$db;uid=sa;pwd=XXXXXX"
 
#If you use Windows Authentication to connect BESMGMT SQL Database, need setup the database
#$connString = "Server=$dbServer;Database=$db;Integrated Security=True"
 
#SQL Query to retrieve BB devices Info (only devices who  recieved mail in the last $days)
$Query = "Select UserConfig.DisplayName,MailboxSMTPAddr,ModelName,LastFwdTime,AppsVer from UserConfig,SyncDeviceMgmtSummary,UserStats where UserConfig.ID=SyncDeviceMgmtSummary.UserConfigID AND UserConfig.ID=UserStats.UserConfigID AND DeviceType <> 0 AND ModelName <> '' AND DateDiff(dd,LastFwdTime,GETDATE()) < "+$days
 
#Connect to Database, run Query, Disconnect
 
$SqlConnection = New-Object 
 
System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = $connString
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = $Query
$SqlCmd.Connection = $SqlConnection
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd
$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)
$SqlConnection.Close()
$bbs = $DataSet.Tables[0]

If you need more details on how to query the BESMGMT database you can read this post or this forum topic, which discusses how to query the database with SQL 2008 CmdLets (you will need to install the Microsoft SQL Server 2008 Feature Pack.) The above script uses the .NET System.Data.SqlClient Namespace, so you won’t need any additional installation. All the information about your user’s Blackberry devices is retrieved in the $bbs variable.

ActiveSync Inventory:

For other mobile devices connecting to your mail system it is more simple because they use the ActiveSync protocol, and all the information you need is stored in the Active Directory. Florian’s blog post explains that msExchActiveSyncDevice objects are a subcontainer of your AD account. Just open dsa.msc to check this out:

Thanks to the Exchange Management Shell (2007 and 2010), the Get-ActiveSyncDeviceStatistics cmdlet gives you all the information you need about the msExchActiveSyncDevice objects. You can read Ben Lye’s post to know how to identify ActiveSync users. With that Cmdlet we will retrieve the following values:

• DeviceType: Mobile type (Iphone, WP, Android…)
• DeviceModel: Mobile model (HTC, LG, Samsung, Iphone…)
• DeviceUserAgent: OS build is displayed in that value (Iphone, WP, Android…)
• LastSuccessSync: Last successful device synchronization, like BlackBerry devices we will filter only users who successfully synchronized during the last 60 days

We retrieve more or less the same information as the one retrieved with the SQL query for Blackberry devices.

How the script works:

We will describe how to aggregate both queries. First we query the BESMGMT SQL database to retrieve Blackberry devices information. For each Email address MailboxSMTPAddr we also check if the user has a device using the ActiveSync protocol (when you are a real VIP you have a Blackberry and an iPad ) by using the following Powershell command:

$acts = Get-ActiveSyncDeviceStatistics -Mailbox $bb.MailboxSMTPAddr
if (($acts | Measure-object).count -eq 0) 
{User has just one BB no ActiveSync device}
else {User has one ActiveSync device in addition to BB}

Once the Blackberry inventory is done we load every Exchange mailbox with this command:

$Mailboxes = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited

Then we compare the PrimarySmtpAddress value (retrieved with the get-mailbox Cmdlet) with every MailboxSMTPAddr value (stored in the $BESsmtpArray variable) in order to exclude the users already processed during the BlackBerry devices inventory. For each remaining user we check if they have any devices using the ActiveSync protocol. The result of the inventory is written in a CSV file containing the following information:

• User’s Email address.
• Number of mobile devices (ActiveSync + BlackBerry).
• Device type: BlackBerry, IPhone, WP, Android…
• Device model: BlackBerry model, Samsung, HTC, LG…
• OS version.
• Last connection: Last mail received on the BlackBerry device, last ActiveSync synchronization.

Here is an example of inventory result imported in Excel:

Just modify the following variables in the script and launch it from the Exchange management shell:

• $days: Inactivity threshold in days (default is 60).
• $dbServer: Name of the server hosting the SQL BES configuration database.
• $connString: Authentication to the SQL database (Windows integrated or with SA account).

To download the full script, just click below:

PS: The script was tested under Exchange 2010 and BES 5.02, thanks for your feedback on other versions.

[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($wsusserver,$False)
$updateScope = new-object Microsoft.UpdateServices.Administration.UpdateScope;
$updateScope.UpdateApprovalActions =[Microsoft.UpdateServices.Administration.UpdateApprovalActions]::Install -bor [Microsoft.UpdateServices.Administration.UpdateApprovalActions]::Uninstall -bor [Microsoft.UpdateServices.Administration.UpdateApprovalActions]:: All -bor [Microsoft.UpdateServices.Administration.UpdateApprovalActions]::NotApproved
 
$updates = $wsus.GetUpdates($updateScope)
 
$groups = $wsus.GetComputerTargetGroups()
 
foreach( $update in $updates){
 
    foreach($group in $groups) {
 
    $status = "Pending"
 
    #MSDN update status:
    #All: Use to query all updates, regardless of their action.
    #Install: Client installs the update.
    #NotApproved :The Update will not be available for clients. This value can be used in a simple targeting ComputerTargetGroup to "override" a UpdateApproval made to the "All Computers" ComputerTargetGroup.
    #Uninstall: Client removes the update.
 
        if ($update.GetUpdateApprovals($group).Count -ne 0)
        {$status = $update.GetUpdateApprovals($group)[0].Action}
    write-host ($update.Title + ';' + $group.Name + ';' + $status)
    }
}

Both test and production target groups inherit from the “All Computers” group:

We need to retrieve the update approval status for the following target groups:

• $Allstatus: Approval status for the ”All computers” group, default value “Not Approved“.
• $statusprod: Approval status for the production target group, default value “Pending“, in this case the approval status inherits from the “All computers” group.
• $statusqualif: Approval status for the test target group, default value “Pending“, in this case the approval status inherits from the “All computers” group.

For a given patch, if $statusprod is different from $statusqualif then the status of each group is returned, if one of the two groups has no value (status pending) then the All computers group approval status is returned.

Download the full script here:

The script returns a CSV file with the following information:

• KB update name.
• Approval status for the production target group, inheritance from the All Computers group is displayed if needed.
• Approval status for the test target group, inheritance from the All Computers group is displayed if needed.
• MSRC severity of the patch (see this MSDN article to get more information on the possible values), this concerns security patches.
• MS Security bulletin the patch is related to, this concerns security patches.
• Products concerned by this update.

In the script, change the following default values:

• $wsusserver: WSUS server name.
• $grqualif: WSUS Target group name for the test computers.
• $grprod: WSUS Target group name for the production computers.

If you want more Powershell scripts about WSUS server management, visit the technet script center.

Ok now you migrated to ADDS 2008R2 you can enjoy many new features like the active directory recycle bin when you forest functional level is 2008R2…

Well when you will start migrating to Windows server 8 ADDS you will get a new feature to make your disaster recovery plan even faster: The ability to do snapshots of a V-DC. I am sure my colleagues Hypervisor and VMDude will appreciate that quote:

Microsoft is working with other virtualization vendors to make sure they include this technology in the latest version of their hypervisors as well. It’s in their interest to do so.

• Autoenrollment is set up for the ldap389-excel-dev group which contains the users authorized to sign Excel macros, the user ldap389-dev is a member of this group.
• Private key: length 2048 bits, not exportable.
• Certificate validity period: 1 year.

Once the Excel certificate template is configured, the certificate will be automatically installed via autoenrollment in the ldap389-dev user’s personal store:

You may want to lock your project before signing it, under the visual basic editor right click on your project, select “Properties”, on the “Protection” tab select the “Lock project for viewing” check box and enter a password. To sign your project navigate to “Tools\Digital Signatures”, click “choose”, the “code signing” certificate installed in your ldap389-dev user’s personal store should appear:

You just signed your VBA project, the certificate validity period is one year. You will need to resign and redeploy the macro before the expiration date
(the 16th of August 2012). After that date the signature will be considered expired and invalid, unless you use a TimeStamp server (RFC 3161 compliant) when signing your VBA project. To achieve that, you should edit the ldap389-dev user’s registry: Edit the key HKEY_CURRENT_USER\Software\Microsoft\VBA\Security as described in the “Office files: enable time-stamping” chapter of this post. This registry setting can be deployed via GPO for the ldap389-excel-dev group. In our case we will use the following registry values:

• TimeStampURL (REG_SZ): http://timestamp.verisign.com/scripts/timstamp.dll.
• TimeStampRetryCount (REG_DWORD): 2.
• TimeStampRetryDelay (REG_DWORD): 2.

Once all your Excel macros are signed by your developers you can enforce the Excel security level with a GPO for all Office versions deployed in your domain, for that you will need to download the “administrative templates” of each Office version:

• Office 2003 SP3 Administrative Template Files (ADM).
• Office 2007 Administrative Template Files (ADM,ADMX/ADML).
• Office 2010 Administrative Template Files (ADM,ADMX/ADML).

You can now setup a GPO that disables all except digitally signed macros for each Excel version:

The above setting is the default one, but it is better to enforce it with a GPO in case it is modified…

If you need a detailed explanation on how loopback processing of group policy works I suggest you read this 4sysops two part blog post (part 1, part 2).

When using loopback processing of group policy on a TS/Citrix server I generally choose the replace mode, in order to discard any specific user settings and get the same environment for each user. The below GPO is applied to the TS/Citrix computer objects located in the same Organizational Unit:

All the servers of our Citrix/TS farm are located in the same OU, there are just two web applications published in our farm, each server hosts only one application. Each application needs a different user configuration, in our case study the IE title bar:

• IE title bar set to “Web Application 1″ for the users member of the “Qualif-Xen-Usr-Param1″ group and logging on the TS/Citrix servers located in the “460-XenApp6″ Organizational Unit and member of the “Qualif-Xen-srv-Param1″ group.
• IE title bar set to “Web Application 2″ for the users member of the “Qualif-Xen-Usr-Param2″ group and logging on the TS/Citrix servers located in the “460-XenApp6″ Organizational Unit and member of the “Qualif-Xen-srv-Param2″ group.

Without using GPP (Group Policy Preferences) you cannot target a specific computer group in order to apply user settings, security filtering will be set up for the “Qualif-Xen-Usr-Param1″ and “Qualif-Xen-Usr-Param2″ user groups. User configuration GPOs linked to the “460-XenApp6″ OU will be as follows:

When a user is member of the “Qualif-Xen-Usr-Param1″ group the IE title bar will be “Web Application 1″, the “Web Application 2″ IE title bar will be displayed if the user is member of the “Qualif-Xen-Usr-Param2″ group. But if the same user is a member of both groups “Quali-Xen-Usr-Param2″ and “Qualif-Xen-Usr-Param1″, the IE title bar “Web Application 1″ will be displayed even if the user logs on a server hosting “Web Application 2″, because of the GPO processing order:

The only way to get the expected behaviour without using GPP is to move the servers hosting “Web Application 1″ and the ones hosting “Web Application 2″ in separate OUs and link each user configuration GPO on each OU. This might not be convenient in terms of administration, because you might end up with as many OUs as applications in your TS/Citrix farm.

When using GPP you have the Item level Targeting feature, which will allow you to leave all you servers in the same OU. The GPO parameter “IE title bar” is just a registry setting, you need to edit the “Window Title” value located under HKEY_CURRENT_USER\Software\Microsft\Internet Explorer\Main. We will use registry GPP and edit that value with “Web Application 1″ if the user belongs to the “Qualif-Xen-Usr-Param1″ and logs on a server member of the “Qualif-Xen-srv-Param1″ group thanks to the item level targeting:

The user configuration GPPs linked to the “460-XenApp6″ OU will look like this:

For a user belonging to both groups “Qualif-Xen-Usr-Param1″ and “Qualif-Xen-Usr-Param2″ the IE title bar will be different if he logs on a server hosting “Web application 1″ or “Web application 2″, that is the expected behaviour

By the way, do not forget to use the GPMC to get the resultant set of policy settings when working with GPP (see my previous post).

As long as the user parameter you want to apply is a registry setting or a common GPP object (shortcut, network drive…) you can use this method to keep your TS/Citrix servers in the same OU when using loopback processing of group policy.