In part one of this series, we looked at how to identify the relevant machines on your network (i.e. machines which are currently offering refuge to PST files), and in part 2 we covered how to use the Exchange Management Shell to identify the filenames, owners and locations of the PST files those machines. This final video will complete the process, and cover the actual import procedure.

In the previous video I identified the machine names of the computers on my network for use in a subsequent search for PST files. In the next video I will look at the scripts that will setup the Import-Mailbox requests from these PSTs into the relevant mailboxes in Exchange.

In the next video I will go through finding PST files on your network.

In Exchange Server 2007 this is not too difficult to accomplish. Microsoft has released a whitepaper on how to configure virtual organizations (i.e. companies) in Exchange Server 2007. This whitepaper can be found on the Technet Website: http://technet.microsoft.com/en-us/library/bb936719(EXCHG.80).aspx – Configuring Virtual Organizations and Address List Segregation in Exchange 2007.

It is tempting to try this in Exchange Server 2010 as well, but you would be best off avoiding doing so. There are a couple of issues (that Microsoft is working on) that will block a successful rollout of Address List Segregation. Besides that, it is not supported and it will also break Exchange Server 2010. More information regarding this can be found on Dave Goldman’s weblog: http://blogs.msdn.com/b/dgoldman/archive/2010/05/10/critical-update-exchange-2010-address-list-segregation-and-current-support-stances.aspx – CRITICAL UPDATE – Exchange 2010 Address List Segregation and Current Support Stances

You may be aware that in Exchange Server 2010 SP1 there’s a /hosting switch, making Exchange Server 2010 SP1 “multi tenant”. This means you can create multiple virtual organizations in Exchange Server 2010 SP1, completely invisible for each other. There’s already quite some information on the Internet regarding installation of Exchange Server 2010 SP1 with the /hosting switch, but most of this information is not coming directly from Microsoft!

This “hoster edition” of Exchange Server 2010 SP1 is targeted towards hosting companies, companies that currently have HMC (Hosted Messaging and Collaboration) 4.5 running. This is basically the Hosted Version of Exchange Server 2007, including Hosted Sharepoint and Hosted OCS. This implementation of Exchange Server 2010 is absolutely not targeted towards enterprise customers!

There are a number of issues you have to be aware of when you want to deploy the “hoster edition” of Exchange Server 2010 SP1:

• You need an SPLA (Service Provider License Agreement) to use this version of Exchange Server 2010 SP1;
• The Forest Functional level is Windows Server 2008;

There is:

• No upgrade path (only a green field scneario);
• No support for Unified Messaging;
• No support for Edge and EdgeSync;
• No support for multiple forests;
• No support for multiple domains;
• No Exchange Management Console;
• No Public Folders;
• No Federation;
• No B2B features such as cross-premises message tracking and calender sharing;
• No IRM;
• No Outlook 2003 support (EnableLegacyOutlook);
• No Support for OCS 2007 R2, only from 3rd party;
• No Support for CRM;

When you try to start the Exchange Management Console you’ll see that it is not supported:

So, all configuration has to be done using the Exchange Management Shell. There’s some additional self service support on the Exchange Control Panel, but basically you’ll need to implement another 3^rd party Control Panel for configuring the Exchange organization. Or create your own Control Panel. Please bare in mind that hosting companies often have dedicated developers that are working on these scenarios.

Conclusion

If you want to implement Address List Segregation on Exchange Server 2010 you cannot use the 2007 version of the Address List Segregation whitepaper. It will break Exchange Server 2010. Although very tempting to use, the Hoster Edition of Exchange Server 2010 SP1 is not an alternative for the enterprise customers. Don’t try it, don’t even think about it, there’s too much complexity for the average enterprise customer. Besides the Service Provider licensing, there’s too much functionality that’s not supported by Microsoft directly, or it is supported by a 3^rd party. The best option is to wait and see if and when Microsoft releases the 2010 version of the Address List Segregation.

The following script does just that:

# Read in pst file locations and users
$strPSTFiles = Get-Content -Path "c:\pstdetails.csv"
foreach($strPSTFile in $strPSTFiles)
{
$strMachine = $strPSTFile.Split(',')[0]
$strPath = $strPSTFile.Split(',')[1]
$strOwner = $strPSTFile.Split(',')[2]

# Get network path for pst file
$source = "\\" + $strMachine + "\" + $strPath.Replace(':','$')

# import pst to mail box.
Import-Mailbox -PSTFolderPath $source -Identity $strOwner
New-MailboxImportRequest -FilePath $source -Mailbox $strOwner
}

The yellow highlighted text shows the Exchange 2010 RTM cmdlet, the red the Exchange 2010 SP1. Delete the unneeded version as appropriate.

The Exchange 2010 SP1 version of the script will execute in far less time, due to the asynchronous nature of the ImportRequest cmdlet. These requests are processed in the background and can be monitored with the Get-MailboxImportRequest cmdlet to observe their status.

There are quite a few potential pitfalls here:

1. The user’s machine must be on.
2. File sharing must be on, to allow for the file to be transferred.
3. Outlook must not be running on the remote user’s machine. If Outlook is running and has the PST file attached, the file will be locked and unable to be imported.
4. The PowerShell cmdlet used by Exchange to import PST files does not support passwords.

There are various things you could to augment this script.Some suggestions include:

•  Have WMI shut down Outlook on a remote user’s machine before attempting import http://www.computerperformance.co.uk/vbscript/wmi_process.htm
• It could be useful to generate a further file detailing a list of all the PSTs which failed to import, with the reason. These files could have been password protected, or the machine hosting them may have been shut down, or become disconnected since they were identified.

I hope you have found this series of articles on manually importing PST files into Exchange 2010 useful. Although, like me, I’m sure you feel that this is a bit of a mammoth task, particularly for the Powershell novice!

To automatically import PST files into Exchange 2010 without Powershell visit:
www.red-gate.com/products/pst_importer_2010. Here you can find out more information on PST Importer 2010 and download a free 14 day trial.

To start this, we  can query Active Directory for a list of all the machines attached to your domain. We can then use Windows Management Instrumentation (WMI) to search each of these machines for PST files. The file paths for these PSTs should hopefully give a clue as to which user they belong to, as they will be created in a directory path containing the username by default. We can also grab the file owner file attribute which should correlate with the file path.

This technique requires that all the machines in your network are switched on and accessible by WMI. A list of the machines which could not be queried can be provided as output

Notes about WMI:

By default WMI is blocked by the windows firewall in Windows 7 and 2008 R2. You’ll need to open up the ports on all your users’ machines. This can be done with the ‘netsh’ command, or through a change to group policy.

What are the implications of this? WMI is a powerful beast, and allows remote access to many aspects of a user’s machine. As such it could be considered a security vulnerability… It’s typically accessed though port 135. This not only permits access to WMI – but also any other DCOM components which may be installed on a machine, open for exploitation by Trojans and the like. Needless to say, the ports are blocked by default for a reason – so require careful consideration of the implications when opening. WMI will also not help you if the machines you wish to tinker with are subject to NAT (Network Address Translation). You’ll be unable to reach these machines. The following script generates a txt file (the filename defined on line 2) of all the computers on your domain to be searched. This can then be edited with notepad to remove those you don’t wish to search.

$strCategory = "computer"
$strOutput = "c:\computernames.txt"
$objDomain = New-Object System.DirectoryServices.DirectoryEntry

$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $objDomain
$objSearcher.Filter = ("(objectCategory=$strCategory)")

$colProplist = "name"
foreach ($i in $colPropList){$objSearcher.PropertiesToLoad.Add($i)}

$colResults = $objSearcher.FindAll()
[bool]$firstOutput = $true
foreach ($objResult in $colResults)
{
$objComputer = $objResult.Properties;
if($firstOutput)
{
Write-output $objComputer.name | Out-File -filepath $strOutput
$firstOutput = $false;
}
else
{
Write-output $objComputer.name | Out-File -filepath $strOutput `
-append
}
}

The next script will generate a CSV (Comma separated values) detailing the network paths of the PSTS you need.

$strComputers = Get-Content -Path "c:\computernames.txt"
[bool]$firstOutput = $true
foreach($strComputer in $strComputers)
{
$colFiles = Get-Wmiobject -namespace "root\CIMV2" `
-computername $strComputer `
-Query "Select * from CIM_DataFile `
Where Extension = 'pst'"
foreach ($objFile in $colFiles)
{
if($objFile.FileName -ne $null)
{
$filepath = $objFile.Drive + $objFile.Path + $objFile.FileName + "." `
+ $objFile.Extension;
$query = "ASSOCIATORS OF {Win32_LogicalFileSecuritySetting='" `
+ $filepath `
+ "'} WHERE AssocClass=Win32_LogicalFileOwner ResultRole=Owner"
$colOwners = Get-Wmiobject -namespace "root\CIMV2" `
-computername $strComputer `
-Query $query
$objOwner = $colOwners[0]
$user = $objOwner.ReferencedDomainName + "\" + $objOwner.AccountName
$output = $strComputer + "," + $filepath + "," + $user
if($firstOutput)
{
Write-output $output | Out-File -filepath c:\pstdetails.csv
$firstOutput = $false
}
else
{
Write-output $output | Out-File -filepath c:\pstdetails.csv -append
}
}
}
}

This script will take as input a text file containing a list of machine names (conveniently the output of the first script), and will generate a csv file of all the pst files found on those machines, and the owners associated with them.

Find PST files across your network quickly and easily with PST Importer 2010. To find out more and to download a free 14 day trial please visit:
www.red-gate.com/products/pst_importer_2010

The lastLogonTimestamp attribute is replicated across all DCs, and it’s important to understand that it does not contain the exact time and date at which the account last logged on.  Instead there is an algorithm which is used to determine when the attribute should be updated, which by default means that the timestamp in lastLogonTimestamp could be up to 14 days old.

To understand the algorithm you need to know that there is a configurable attribute in AD called msDS-LogonTimeSyncInterval, which controls the granularity of updates to lastLogonTimestamp.  By default it is not set, which means that the default value of 14 is used.  There is also some randomization involved to ensure that simultaneous updates from many accounts don’t cause large replication loads on the DCs.  The randomization factor is a random percentage of 5 days.

The algorithm means that when a user or computer logs on the lastLogonTimestamp is only updated if the current value of lastlogonTimestamp is older than ([current date] – [14 days] + [random percentage of 5 days]).  This means that the value of lastLogonTimestamp for an active account could be anything from 9-14 days old.

The last thing to know about lastLogonTimestamp is that the value is stored in UTC format as a large integer, so needs some manipulation to get into human-readable form.

Now that we understand how the attribute works we can use it to do something useful, like find all enabled computer accounts in the domain which have not logged on for 60 or more days.  PowerShell is particularly suited to this because it has built-in methods for doing the date conversions.

# Calculate the UTC time 60 days ago, in FileTime (Integer) format and convert it to a string

$LLTSlimit = (Get-Date).AddDays(-60).ToFileTimeUTC().ToString()

# Create the LDAP filter for the AD query

# Searching for enabled computer accounts which have lastLogonTimestamp older than 60 days

$LDAPFilter = "(&(objectCategory=Computer)(lastlogontimestamp<=$LLTSlimit) (!(userAccountControl:1.2.840.113556.1.4.803:=2)))"

# Create an ADSI Searcher to query AD

$Searcher = new-object DirectoryServices.DirectorySearcher([ADSI]"")

$Searcher.filter = $LDAPFilter

# Execute the query

$Accounts = $Searcher.FindAll()

# Process the results

If ($Accounts.Count –gt 0) {

# Create an array to store all the results

$Results = @()

# Loop through each account

ForEach ($Account in $Accounts) {

# Create an object to store this account in

$Result = "" | Select-Object Name,ADSPath,lastLogonTimestamp

# Add the name to the object as a string

$Result.Name = [String]$Account.Properties.name

# Add the ADSPath to the object as a string

$Result.ADSPath = [String]$Account.Properties.adspath

# Add the lastLogonTimestamp to the object as a readable date

$Result.lastLogonTimestamp = `

[DateTime]::FromFileTime([Int64]::Parse($Account.Properties.lastlogontimestamp))

# Add this object to our array

$Results = $Results + $Result

}

}

# Output the results

$Results | Format-Table -autosize

Extending this script to disable the discovered accounts is as easy as adding this code snippet to the end:

# Disable each account

ForEach ($Result in $Results) {

$ADSIAccount = [ADSI]$Result.ADSPath

$ADSIAccount.PSBase.InvokeSet("AccountDisabled", "True")

$ADSIAccount.SetInfo()

}

The lastLogonTimestamp attribute is useful for system administrators to understand, and because PowerShell can handle all the type conversions and date arithmetic, it is a great tool to use when working with it.