The LDAP389-ACTIVESYNC group has two members: One group containing the users located in Paris, the second with the users located in London. Members of each group (PAR-ALLOWACTIVESYNC and LON-ALLOWACTIVESYNC) are managed by each local IT team:

In order to retrieve the users allowed to use the ActiveSync protocol we will get recursively the members of the LDAP389-ACTIVESYNC group:

$groupDN = "CN=LDAP389-ACTIVESYNC,OU=Groups,OU=HQ,DC=ldap389,DC=local"
$members = Get-ADGroupMember -Identity $groupDN -Recursive | Get-ADUser -Properties mail

We will also retrieve the mailboxes which are allowed to use the ActiveSync protocol:

$allcas = get-mailbox -ResultSize:unlimited | Get-CASMailbox
$users= $allcas | where-object {$_.ActiveSyncEnabled -eq $true}

Firstly the script will browse the mailbox accounts which are allowed to use the ActiveSync protocol ($users), if one of these accounts is not a member of the LDAP389-ACTIVESYNC group then ActiveSync is disabled with the Set-CASMailbox cmdlet (ActiveSyncEnabled parameter).

Secondly the script will browse the members of the LDAP389-ACTIVESYNC group ($members), if for one of these accounts ActiveSync is disabled, the script enables it, with the Set-CASMailbox cmdlet as well.

To download the full script, just click on the link below:

Now we need to set up the scheduled task which will run with a service account, this user should have the following rights:

• Read the Active Directory objects.
• Local administrator of the machine the task is running on.
• Create a custom RBAC role, in order to grant only the necessary Exchange rights to achieve the task.

In order to create the “Disable ActiveSync” role, we create a new management role using the default “Mail Recipients” role as a parent.

New-ManagementRole -Parent "Mail Recipients" -Name "Disable ActiveSync"

The script uses only the three following cmdlets: Get-Mailbox, Get-CASMailbox, Set-CASMailbox. So we will remove all the cmdlets from the role except those three:

Get-ManagementRoleEntry "Disable ActiveSync\*" | Where { (($_.Name -ne "Get-Mailbox") -and ($_.Name -ne "Set-CASMailbox") -and ($_.Name -ne "Get-CASMailbox")) } | Remove-ManagementRoleEntry

We will also remove some of the allowed parameters from the Set-CASMailbox cmdlet for the “Disable ActiveSync” role, except the parameters used by our script:

Set-ManagementRoleEntry "Disable ActiveSync\Set-CASMailbox" -Parameters Identity,ActiveSyncEnabled,whatif,confirm

Finally we create the management role AD group called “EnableMobileAccess” corresponding to the “Disable ActiveSync” role.

New-RoleGroup -Name EnableMobileAccess
New-ManagementRoleAssignment -Name ManageMobileAccess -Role "Disable ActiveSync" -SecurityGroup EnableMobileAccess

Just add the service account to the newly created group and set up your Exchange scheduled task with this account. The connection to the Exchange remote shell is already included in the script. The scheduled task will run with a service account that will just have the necessary rights, no more.

For each machine (Physical server, Virtual Machine, ESX host) we retrieve:

• The machine name.
• The machine physical model, if this is a Virtual Machine “VM” is returned.
• The total number of CPUs of the machine.
• The total number of Cores of the machine.
• Total RAM of the machine.
• OS of the machine. For the Windows Server machines, we also return the Edition (Enterprise, Standard, Datacenter). For the ESX hosts, “ESX” is returned.

For each ESX host we return the Virtual Machines running on it. The Virtual Machines positions are a snapshot picture at the time the script is running. Your Virtual Machines might move later to another ESX host because of the DRS mechanism. Below is an example of result file retrieved with the script:

In order to achieve this inventory we will use PowerCli, WMI and the AD Cmdlets. Firstly we will retrieve all the servers which have been active during the last 90 days:

$d = [DateTime]::Today.AddDays(-90)
$servers = Get-ADComputer -searchbase "DC=ldap389,DC=info" -Properties OperatingSystem, OperatingSystemServicePack -Filter 'PasswordLastSet -ge $d' | Where-Object {$_.OperatingSystem -like ‘*server*’}

Then we retrieve the Windows OS edition of each computer account. For Windows 2008 servers, that information is stored in the OperatingSystem account attribute. For other versions, the edition is retrieved by querying the server with the Win32_OperatingSystem WMI class. In order to compute the total number of CPUs and Cores of each Windows server we will use the Win32_Processor WMI class. Under Windows 2003, the computing method os different depending on wether or not you patched your OS with KB932370.

For Windows 2008 and patched Windows 2003 Operating systems:

$Win32_cpu = Get-WmiObject -class win32_processor -computer $ServerName
$NbCPUs = ($Win32_cpu | measure-object).count
$Nbcores = ($Win32_cpu | measure-object NumberOfCores -sum).sum

For non patched Windows 2003 OS (read this post for more details):

$physCount = new-object hashtable
$Win32_cpu = Get-WmiObject -class win32_processor -computer $ServerName
$Win32_cpu |%{$physCount[$_.SocketDesignation] = 1}
$NbCPUs = $physCount.count
$Nbcores = ($Win32_cpu | measure-object).count

If the Manufacturer value returned by the Win32_ComputerSystem WMI class is equal to VMware, Inc. the server is a VMWare virtual machine: In that case we retrieve the ESX host on which the VM is running. The virtual machines are sorted by ESX host: Thanks to a hashtable with the ESX hosts names containing hashtables with the Virtual machines of each ESX host. Read this article on how to manipulate a hashtable that contains hashtables. The common value between the AD computer object and the Virtual Machine PowerCli object is the DNSHostname AD attribute and the Hostname value stored in the Guest object of the VM (thanks NiTRo for that tip). That way the script will run even if your Virtual Machine names are not equal to your server hostnames.

If the server is a physical machine, we write the result directly in the output file.

Once we have retrieved all the ESX hosts names and VMs information, we retrieve physical information (Model, total CPUs, total cores, RAM) for each ESX host by using PowerCli, as described in this post:

$hard = (get-vmhost $esx).Extensiondata.Summary.Hardware
$mem = [int] ($hard.MemorySize/1mb)
$NbCPUs = $hard.NumCpuPkgs
$Nbcores = $hard.NumCpuCores
$model = $hard.Model

To download the full script just click on the link below:

Launch the script in a PowerCli session and do not forget to import the AD module (import-module ActiveDirectory): There we go, we used WMI, PowerCli and the AD Cmdlets in a single script

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.