Posted by

Mike Crowley

Posted on

June 24, 2014

Posted under

Office365

Comments

8 Comments

What are the Azure DirSync Cmdlets [Updated]?

ARTICLE UPDATED August 2014 to address the PowerShellConfig module.

NOTE: If you are using Azure AD Connect, see this new article.

As you may have seen, DirSync’s PowerShell functionality can now be called from the “Import-Module” cmdlet instead of running a custom DirSyncConfigShell.psc1 file. If we look at this new module, we can see 92 DirSync-related cmdlets:

DirSync PowerShell Module

Notice the screenshot is actually listing the commands of the “Microsoft.Online.Coexistence.PS.Config module” and “PowerShellConfig” (very descriptive!), not “DirSync”. That is because the DirSync module is a wrapper of sorts, calling “%programfiles% \Windows Azure Active Directory Sync\dirsync\DirSync.psd1” on your behalf. The DirSync module itself contains no cmdlets.

So, what do these cmdlets do anyway? Not all of them are well documented online, so you should start with the help file. Unfortunatley, even the help file omits a synopsis for the 67 “PowerShellConfig” cmdlets. For the 25 within Microsoft.Online.Coexistence.PS.Config module, run the below command to generate an output similar to the following table:

ipmo DirSync
gcm -m Microsoft.Online.Coexistence.PS.Config | get-help | select name, synopsis | epcsv $env:userprofile\desktop\DirSyncCmdlets.csv -notype

Name	Synopsis
Disable-DirSyncLog	This commandlet is used to disable logging for the Azure Active Directory Sync tool.
Disable-MSOnlineObjectManagement	Disable-MSOnlineObjectManagement -Credential <pscredential> [-ObjectTypes <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]
Disable-MSOnlinePasswordSync	Disable-MSOnlinePasswordSync -Credential <pscredential> [-WhatIf] [-Confirm] [<CommonParameters>]
Disable-MSOnlineRichCoexistence	Disable-MSOnlineRichCoexistence -Credential <pscredential> [-WhatIf] [-Confirm] [<CommonParameters>]
Disable-OnlinePasswordWriteBack	This commandlet is used to disable writing back user password resets from cloud to onpremise Active Directory.
Disable-PasswordSyncLog	This commandlet is used to disable logging for the Password Sync feature of the Azure Active Directory Sync tool.
Enable-DirSyncLog	This commandlet is used to configure the logging level for the Azure Active Directory Sync tool.
Enable-MSOnlineObjectManagement	Enable-MSOnlineObjectManagement -ObjectTypes <string[]> -TargetCredentials <pscredential> -Credential <pscredential> [-WhatIf] [-Confirm] [<CommonParameters>]
Enable-MSOnlinePasswordSync	Enable-MSOnlinePasswordSync -Credential <pscredential> [-WhatIf] [-Confirm] [<CommonParameters>]
Enable-MSOnlineRichCoexistence	Enable-MSOnlineRichCoexistence -Credential <pscredential> [-WhatIf] [-Confirm] [<CommonParameters>]
Enable-OnlinePasswordWriteBack	This commandlet is used to enable writing back user password resets from cloud to onpremise Active Directory.
Enable-PasswordSyncLog	This commandlet is used to configure the logging level for the Password Sync feature of the Azure Active Directory Sync tool.
Get-CoexistenceConfiguration	Gets a configuration information from the Microsoft Online Coexistence Web Server
Get-DirSyncConfiguration	Get-DirSyncConfiguration -TargetCredentials <pscredential> [<CommonParameters>]
Get-DirSyncLogStatus	This commandlet is used to retrieve the current logging level for the Azure Active Directory Sync tool.
Get-OnlinePasswordWriteBackStatus	This commandlet is used to obtain the current status of writing back user password resets from cloud to onpremise Active Directory.
Get-PasswordSyncLogStatus	This commandlet is used to retrieve the current logging level for the Password Sync feature of the Azure Active Directory Sync tool.
Get-PreventAccidentalDeletes	This commandlet is used to retrieve the current status of the object deletion threshold for DirSync.
Set-CoexistenceConfiguration	Configures Microsoft Online Directory Synchronization Tool.
Set-CompanyDirSyncFeatures	Set-CompanyDirSyncFeatures -TargetCredentials <pscredential> -FeaturesFlag <int> [<CommonParameters>]
Set-DirSyncConfiguration	Set-DirSyncConfiguration -TargetCredentials <pscredential> -DirSyncConfiguration <CloudDirSyncConfiguration> [<CommonParameters>]
Set-FullPasswordSync	Resets the password sync state information forcing a full sync the next time the service is restarted.
Set-PreventAccidentalDeletes	This commandlet is used to enable or disable the object deletion threshold for DirSync.
Start-OnlineCoexistenceSync	Starts synchronization with Microsoft Online
Update-MSOLDirSyncNetworkProxySetting	Updates the directory sync service to use the current user’s http proxy settings.

The de-“magicification” of DirSync is definitely a good thing for all Azure customers. Having said this, I’d still keep the Codeplex FIM modules around, since they do offer a lot more control of and visibility into the underlying FIM Sync Service.

Here are the cmdlets without help documentation:

Add-AttributeFlowMapping

Add-ConfigurationParameter

Add-ConnectorAnchorConstructionSettings

Add-ConnectorAttributeInclusion

Add-ConnectorFilter

Add-ConnectorHierarchyProvisioningMapping

Add-ConnectorObjectInclusion

Add-RelationshipConditionGrouping

Add-RunStep

Add-SynchronizationConditionGrouping

Disable-ConnectorPartition

Disable-ConnectorPartitionHierarchy

Enable-ConnectorPartition

Enable-ConnectorPartitionHierarchy

Export-ServerConfiguration

Get-AADConnectorPasswordResetConfiguration

Get-ConfigurationParameter

Get-Connector

Get-ConnectorHierarchyProvisioningDNComponent

Get-ConnectorHierarchyProvisioningMapping

Get-ConnectorHierarchyProvisioningObjectClass

Get-ConnectorPartition

Get-ConnectorPartitionHierarchy

Get-ConnectorTypes

Get-GlobalSettings

Get-PasswordHashSyncConfiguration

Get-RunProfile

Get-Schema

Get-SynchronizationRule

Import-MIISServerConfig

Import-ServerConfiguration

Initialize-Connector

Initialize-RunProfile

Initialize-SynchronizationRule

New-Connector

New-RunProfile

New-SynchronizationRule

Remove-AADConnectorPasswordResetConfiguration

Remove-AttributeFlowMapping

Remove-ConfigurationParameter

Remove-Connector

Remove-ConnectorAnchorConstructionSettings

Remove-ConnectorAttributeInclusion

Remove-ConnectorFilter

Remove-ConnectorHierarchyProvisioningMapping

Remove-ConnectorObjectInclusion

Remove-PasswordHashSyncConfiguration

Remove-RelationshipConditionGrouping

Remove-RunProfile

Remove-RunStep

Remove-SynchronizationConditionGrouping

Remove-SynchronizationRule

Set-AADConnectorPasswordResetConfiguration

Set-ConfigurationParameter

Set-Connector

Set-GlobalSettings

Set-MIISADMAConfiguration

Set-MIISECMA2Configuration

Set-MIISExtMAConfiguration

Set-MIISFIMMAConfiguration

Set-PasswordHashSyncConfiguration

Set-ProvisioningRulesExtension

Set-RunProfile

Set-Schema

Set-SynchronizationRule

Update-ConnectorPartition

Update-ConnectorSchema

As time allows, I will return with more detail on each of the above DirSync cmdlets; so long for now!

Posted by

Mike Crowley

Posted on

April 17, 2014

Posted under

Office365

Comments

Backup and Restore Instructions for the DirSync Database

Today, Microsoft released a 9 page guide on backing up and restoring the Microsoft Azure Active Directory Sync tool. You can get it here.

Some things to keep in mind:

This guide applies to DirSync when used with the full version of SQL only. This means it does not apply to most installations.
You don’t need to backup or restore DirSync. If you simply install a new instance and configure it appropriately, the objects will re-sync. Doing a backup/restore can save time however, if you have a very large number of users (I wouldn’t bother with less than 100k).
Ironically, this guide doesn’t actually tell you how to backup or restore the database. You need some SQL-aware backup product to do that. Instead, this guide helps you make use of a restored database in a DirSync environment (working with miisclient.exe, handling keys, etc).

Posted by

Mike Crowley

Posted on

February 3, 2014

Posted under

Office365

Comments

4 Comments

DirSync 1.0.6593.0012

Late Monday, Microsoft released another update to the DirSync software, this time with a build number of 6593.0012. You can download it in from the usual link.

DirSync 1.0.6593.0012

As with previous DirSync updates, there has been no official announcement of the release, however the “use at your own risk” Wiki does mention one of the new features:

*Version*	6593.0012
*Date Released*	2/3/2014
*Notable Changes*

New features:

Additional Attributes are synchronized on User and Contact objects

Attributes documented here

The new attributes referenced in the link are userCertificate and userSMIMECertificate. Interestingly pwdLastSet was also added, however there is no mention of that one in the article. These additions serve an unknown purpose for now, however one might speculate that they are in support of new capabilities soon to be available in the service?!

Before you upgrade, you may wish to get a “before and after” review of the attribute inclusion list. The best way to review this is in the “Configure Attribute Flow” area of each management agent. At the end of this post, I have also shared an experimental PowerShell method of getting this information.

It is noteworthy that the author of this update, a Microsoft Program Manager for DirSync, is linking to yet another community wiki page instead of the seemingly defunct Knowledge Base article KB-2256198. Sadly, it would appear that the crumbling integrity of the TechNet/Support documentation may be latest casualty in a growing list of IT Pro-related cuts Microsoft has made along their quest to the cloud…

<#
Description:
This script counts and dumps the attribute inclusion lists from each MA.
It does not evaluate attribute flow or applicable object types.

February 3 2014
Mike Crowley
http://mikecrowley.us
#>

#Import Modules
Import-Module SQLps -WarningAction SilentlyContinue

#Get SQL Info
$SQLServer = (gp 'HKLM:SYSTEM\CurrentControlSet\services\FIMSynchronizationService\Parameters').Server
if ($SQLServer.Length -eq '0') {$SQLServer = $env:computername}
$SQLInstance = (gp 'HKLM:SYSTEM\CurrentControlSet\services\FIMSynchronizationService\Parameters').SQLInstance
$MSOLInstance = ($SQLServer + "\" + $SQLInstance)

#Get Management Agent Attribute Info
[xml]$OnPremAttributes = (Invoke-Sqlcmd -MaxCharLength 10000 -ServerInstance $MSOLInstance -Query "SELECT attribute_inclusion_xml FROM [FIMSynchronizationService].[dbo].[mms_management_agent] WHERE [ma_name] = 'Active Directory Connector'").attribute_inclusion_xml
[xml]$CloudAttributes = (Invoke-Sqlcmd -MaxCharLength 10000 -ServerInstance $MSOLInstance -Query "SELECT attribute_inclusion_xml FROM [FIMSynchronizationService].[dbo].[mms_management_agent] WHERE [ma_name] = 'Windows Azure Active Directory Connector'").attribute_inclusion_xml
$ADAttributes = $OnPremAttributes.'attribute-inclusion'.attribute
$AzureAttributes = $CloudAttributes.'attribute-inclusion'.attribute

#Output to Screen
Write-Host $ADAttributes.count "Attributes synced from AD to the Metaverse" -F Cyan
Write-Host $AzureAttributes.count "Attributes synced from the Metaverse to Azure" -F Cyan
Write-Host "See" $env:TEMP\DirSyncAttributeList.txt "for detail" -F Cyan

#Output to File
"******AD Attributes******" | Out-File $env:TEMP\DirSyncAttributeList.txt
$ADAttributes | Out-File $env:TEMP\DirSyncAttributeList.txt -Append
" "| Out-File $env:TEMP\DirSyncAttributeList.txt -Append
"******Azure Attributes******" | Out-File $env:TEMP\DirSyncAttributeList.txt -Append
$AzureAttributes | Out-File $env:TEMP\DirSyncAttributeList.txt -Append

##END

Posted by

Mike Crowley

Posted on

November 22, 2013

Posted under

Office365

Comments

11 Comments

DirSync 1.0.6567.0018 Has Been Released

As some of us noticed, last week, Microsoft quietly removed the latest version of DirSync without so much as a tweet explaining why. Word on the street is that there were issues in the “Export” stage in the synchronization process (see KB 2906832). Today it would appear those issues have been resolved, as v1.0.6567.0018 just hit the web. You can download it here, though I’d advise caution, given Microsoft’s approach to communicating (lack-thereof) bugs.

As stated in the updated Wiki, the following improvements exist in this version:

New features:

DirSync can be installed on a Domain Controller (must log-off/log-on AFTER installation and BEFORE configuration wizard)
- Documentation on how to deploy can be found here

Contains fixes for:

Sync Engine memory leak issue
Sync Engine export issue (FIM 2010 R2 hotfix 4.1.3493.0)
“Staging-Error” during large Confirming Imports from Windows Azure Active Directory
password sync behavior when sync’ing from Read-Only Domain Controllers (RODC)
DirSync setup behavior for domains with ‘@’ symbol in NetBois names
Fix for Hybrid Deployment Configuration-time error:
- EventID=0
- Description like “Enable-MsOnlineRichCoexistence failed. Error: Log entry string is too long. A string written to the event log cannot exceed 32766 characters.”

Posted by

Mike Crowley

Posted on

November 5, 2013

Posted under

Office365

Comments

18 Comments

Upgrading DirSync to the Latest Version

EDIT (Nov. 22 2013): DirSync 1.0.6567.0018 Has Been Released

EDIT (Nov. 11 2013): DirSync 1.0.6553.2 has been removed from Microsoft’s download site and version history comment removed from the Wiki. Not sure why.

Early this morning, Microsoft released an updated version of Windows Azure Active Directory Sync tool (DirSync to you and me). Version 1.0.6553.2 (or later) can be downloaded from the usual link. It comes with 4 known improvements:

Fix to address Sync Engine memory leak
Fix to address “staging-error” during full import from Azure Active Directory
Fix to handle Read-Only Domain Controllers in Password Sync
DirSync can be installed on a Domain Controller. Documentation on how to deploy can be found here.

I am most excited about #4, as this enables me to build more interesting labs from my laptop, now that I don’t need a dedicated “DirSync Server”. You should note however, this is recommended only for “development” environments. After some further testing, I’d consider recommending this configuration for shops with multiple domain controllers and 50 or fewer users.

If you’re already running DirSync, and want to upgrade, you’re likely in one of two camps:

You want to move DirSync from a dedicated server to a DC.
You don’t want to move the DirSync server to a DC (or elsewhere), you just want the latest version.

If you’re in the first scenario, I’m going to assume you’re working in a lab or very small environment. This means you don’t need to worry about a lengthy synchronization process, and can easily take advantage of the built-in soft-match capability of the product. Your upgrade process is easy:

Throw away your existing DirSync server.
Install Dirsync on a DC.
Run the Directory Sync Configuration Wizard

As soon as you finish the 3^rd step, the initial synchronization will rebuild the database (and re-sync passwords), returning to where you left off!

NOTE: If you’re a big shop, you should consider that a full sync takes roughly 1 hour per 5,000 objects synced, according to a recent webcast by Lucas Costa. Soft-matches would likely go faster, but you’ve been warned…

Now, if you’re just looking to upgrade your version of DirSync to the latest version, you need to first ensure you are running versoin 6385.0012 or later. In-place upgrades aren’t supported on earlier versions. If this is you, refer to the soft-match advice I gave above. This is your upgrade path.

For those that are running 6385.0012 or later, upgrading is as simple as a few clicks of the mouse. For the nervous, here are some screenshots:

NOTE: The installer detects an existing installation.

This is the default path, but it should reflect your installation directory.
Hmm, that’s not good! Fortunately a reboot cleared this up for me, but if you’re not so lucky, you can examine the following logs: coexistenceSetup dirsyncSetup miissetup MSOIDCRLSetup …which are located in the earlier discussed installation directory.
Much better!
For an upgrade, you’ll want to run this right away, since not doing so leaves you without a functioning DirSync server.

Global Office 365 Administrator credentials go here. This is stored on your DirSync server, so make sure PasswordNeverExpires attribute is set to $true on the Office 365 account (or your on-premises account, if you’re using a federated user)
On-Premises Enterprise Admin credentials go here:
Checking this box allows some attributes to be written back to your Active Directory, which is necessary for a Hybrid Exchange Server scenario.
Enable Password Sync… or Don’t.

NOTE: Upgrades and new installs require a Full Sync.
This post wouldn’t be complete without a plug for my free DirSync Report script!

Posted by

Mike Crowley

Posted on

May 14, 2012

Posted under

Active Directory, Exchange Server, Office365

Comments

10 Comments

Converting SMTP Proxy Addresses to Lowercase

Update: Be aware, this script has not been tested with SIP, X400 or other address types. I am working on an update to validate these scenarios, but in the meantime, proceed at your own risk with these address types.

I recently encountered a question in an online forum where someone asked for a script to convert all of their user’s email addresses to lower case values. While this doesn’t affect the message delivery, it can have an impact on aesthetics when the address is displayed in an external recipient’s email client. An Exchange Email Address Policy can do this to some degree, but I wanted to see how it could be done with PowerShell.

The challenge with a script like this is twofold:

Email addresses (proxy addresses) are a multi-valued attribute, which can be tricky to work with.
PowerShell is generally not case-sensitive, and therefore when we try to rename Mr. Gallalee’s email address in the screenshot below, we can see that it does not work:

After a little bit of inspiration from a script written by Michael B Smith, I came up with the below:


$MailboxList = Get-Mailbox  -ResultSize unlimited

$MailboxList | % {

$LoweredList = @()
$RenamedList = @()

foreach ($Address in $_.EmailAddresses){
if ($Address.prefixstring -eq "SMTP"){
$RenamedList += $Address.smtpaddress + "TempRename"
$LoweredList += $Address.smtpaddress.ToLower()
}
}
Set-mailbox $_ -emailaddresses $RenamedList -EmailAddressPolicyEnabled $false
Set-mailbox $_ -emailaddresses $LoweredList

#Without this line the "Reply To" Address could be lost on recipients with more than one proxy address:
Set-mailbox $_ -PrimarySmtpAddress $_.PrimarySmtpAddress
}

This script works as follows:

Puts all mailboxes into the $MailboxList variable. If you don’t want all mailboxes, edit the Get-Mailbox cmdlet as you see fit.
Filters out X400 and other non-SMTP addresses.
Creates an array called $RenamedList which stores each proxy address with “TempRename” appended to it (e.g. Rgallalee@demolab.localTempRename).
Creates another array ($LoweredList) and use the “ToLower” method on each proxy address.
Sets the proxy address for the user to the value of $RenamedList and then to $LoweredList.
1. This is how we get around the case case insensitivity – name it to something else and then name it back.
Step 4 and 5 don’t preserve the “Primary” / “Reply-To” address, so we set it back manually with the last line.

Note: This script turns off the email address policy for each user.

As always, feedback is welcome.

EDIT Dec 2018:
This is a similar approach, but for mailboxes migrated to Office 365. In this case, only the Primary SMTP addresses are targeted.

It may also be faster than the above, due to the fact we’re only operating against mailboxes that have uppercase (vs all of them).

Set-ADServerSettings -ViewEntireForest:$true

$TargetObjects = Get-RemoteMailbox -ResultSize Unlimited | Where {$_.PrimarySmtpAddress.ToLower() -cne $_.PrimarySmtpAddress}

Write-Host $TargetObjects.count "Remote mailboxes have one or more uppercase characters." -ForegroundColor Cyan

#Backup First
Function Get-FileFriendlyDate {Get-Date -format ddMMMyyyy_HHmm.s}
$DesktopPath = ([Environment]::GetFolderPath("Desktop") + '\')
$LogPath = ($DesktopPath + (Get-FileFriendlyDate) + "-UppercaseBackup.xml")

$TargetObjects | select DistinguishedName, PrimarySMTPAddress, EmailAddresses | Export-Clixml $LogPath
Write-Host "A backup XML has been placed here:" $LogPath -ForegroundColor Cyan
Write-Host

$Counter = $TargetObjects.Count

foreach ($RemoteMailbox in $TargetObjects) {

    Write-Host "Setting: " -ForegroundColor DarkCyan -NoNewline
    Write-Host $RemoteMailbox.PrimarySmtpAddress -ForegroundColor Cyan
    Write-Host "Remaining: " -ForegroundColor DarkCyan -NoNewline
    Write-Host $Counter -ForegroundColor Cyan

    Set-RemoteMailbox $RemoteMailbox.Identity -PrimarySmtpAddress ("TMP-Rename-" + $RemoteMailbox.PrimarySmtpAddress) -EmailAddressPolicyEnabled $false
    Set-RemoteMailbox $RemoteMailbox.Identity -EmailAddresses @{remove = $RemoteMailbox.PrimarySmtpAddress}

    Set-RemoteMailbox $RemoteMailbox.Identity -PrimarySmtpAddress $RemoteMailbox.PrimarySmtpAddress.ToLower()
    Set-RemoteMailbox $RemoteMailbox.Identity -EmailAddresses @{remove = ("TMP-Rename-" + $RemoteMailbox.PrimarySmtpAddress)}

    $Counter --
}

Write-Host
Write-Host "Done." -ForegroundColor DarkCyan

#End

Posted by

Mike Crowley

Posted on

April 17, 2012

Posted under

Active Directory, Exchange Server, Office365

Comments

29 Comments

Combining PowerShell Cmdlet Results

In my last post I used used New-Object to create an desirable output when the “Get-Mailbox” cmdlet didn’t meet my needs. If your eyes glazed over trying to read the script, let me make it a bit simpler by focusing on a straight forward example.

Say you need to create a list of user’s mailbox size with their email address. This sounds like a simple request, but what you’d soon find is that mailbox sizes are returned with the Get-MailboxStatistics cmdlet and the email address is not. For that, you need to use another cmdlet, such as Get-Mailbox.

With the New-Object cmdlet, we are able to make a custom output that contains data from essentially wherever we want.

See this example:

$MyObject = New-Object PSObject -Property @{
EmailAddress = $null
MailboxSize = $null
}

In this example, I have created a new object with 2 fields, and saved it as the $MyObject variable.

For now, we’ve set the data to null, as shown below:

The next step is to populate each of those fields. We can write to them one at a time with lines like this:

$MyObject.EmailAddress = (Get-Mailbox mcrowley).PrimarySmtpAddress
$MyObject.MailboxSize = (Get-MailboxStatistics mcrowley).TotalItemSize

Note: The variable we want to populate is on the left, with what we want to put in it on the right.

To confirm our results, we can simply type the variable name at the prompt:

Pretty cool, huh?

Ok, so now about that list. My example only shows the data for mcrowley, and you probably need more than just 1 item in your report, right?

For this, you need to use the foreach loop. You can read more about foreach here, but the actual code for our list is as follows:

(I am actually going to skip the $null attribute step here)

$UserList = Get-mailbox -Resultsize unlimited
$MasterList = @()
foreach ($User in $UserList) {
$MyObject = New-Object PSObject -Property @{
EmailAddress = (Get-Mailbox $User).PrimarySmtpAddress
MailboxSize = (Get-MailboxStatistics $User).TotalItemSize
}
$MasterList += $MyObject
}
$MasterList

Finally, if you wanted to make this run faster, we really don’t need to run “get-mailbox” twice. For better results, replace the line:

EmailAddress = (Get-Mailbox $User).PrimarySmtpAddress

With this one:

EmailAddress = $User.PrimarySmtpAddress

Posted by

Mike Crowley

Posted on

November 21, 2011

Posted under

Office365

Comments

14 Comments

Office 365 DirSync (x64) Installation Walkthrough

EDIT: This article seems to be popular, however readers should note it is from 2011! Check out the updated article here:

Upgrading DirSync to the Latest Version

—————-

As Microsoft has already stated, the new 64-bit version of DirSync.exe is not installed or configured differently than its 32-bit predecessor. However, as a tinkerer, I wanted to verify this and have a look under the hood anyway!

Below are some screenshots of my experiences and insights along the way:

Before you start: Read and follow the instructions! In this article, I assume you’re at the point where you’re actually ready to install this product.

1. First I installed the .Net Framework prerequisites as well as my favorite MMC snap-ins onto a new Windows 2008 R2 server. You can do this using the following two lines in PowerShell	Import-Module ServerManagerAdd-WindowsFeature NET-Framework,RSAT-ADDS -Restart
2. Then I ran dirsync.exe (downloaded from the portal.microsoftonline.com site).a. NOTE: Microsoft didn’t bother to change the installer’s executable name (dirsync.exe). This may be confusing if you plan to download and store both x86 and x64 versions.
3. A few clicks of the “Next” button…
a. NOTE: We install to the “Program Files” directory. If this were a x86 application we’d be using “\Program Files (x86)”
b. NOTE: This screen may take 5-10 minutes. It’s installing a few things in the background:i. SQL 2008 R2 Expressii. Forefront Identity Manager 2010 (FIM)iii. Configuration of the FIM Management Agents (MAs)
…
4. Once the background tasks have completed, you’re able to run the Configuration Wizard. This is where you will need to have your Office 365 tenant prepared and credentials identified, etc.
5. Next…
6. You should have created this account earlier. Whatever you put in here will be stored within FIM, and if you ever change the credentials, you’ll need to re-run this setup wizard.
a. Or for the expert user: Dive into FIM directly
7. Here you need to supply your forest’s Enterprise Admin credentials. This username is not saved anywhere, and is only needed once to set permissions for these new objects:a. Yourdomain\MSOL_AD_Syncb. Yourdomain\MSOL_AD_Sync_RichCoexistence
8. Selecting this box enables some extra features required for a “hybrid deployment” / “rich coexistence”, and by doing so you’ll allow FIM to update attributes IN YOUR Active Directory. If this box is not checked, FIM will read-only.
9. Next..
10. If you’re ready, you can run the initial full synchronization now. Otherwise, you can run it manually at any time.a. Once configured, DirSync runs every 3 hours.
11. If you promise to be careful, you can poke around in the FIM configuration. a. Note the “hidden” client UIb. If you get an error when opening the FIM console, log out and then back in. Your account was added to some groups that are not yet part of your login ticket.c. Clicking the Management Agents tab shows both sides of your configuration. “TargetWebService” is responsible for all of the Office 365 configurations and the “SourceAD” management agent contains your Active Directory connector information (double-click them to open).NOTE: Changing the DirSync configuration directly within FIM is unsupported by Microsoft. They would prefer you rerun the previously mentioned Configuration Wizard if you need to make any changes.	C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe
12. Finally, be sure to run Microsoft Update again. You’ll notice that SQL 2008 R2 does not have SP1.

Posted by

Mike Crowley

Posted on

November 17, 2011

Posted under

Office365

Comments

1 Comment

A New Version Of Office 365’s Directory Synchronization Tool Has Arrived!

Most medium and large organizations using Microsoft’s Office 365 service will also be using “DirSync” to provision and manage user identities. Until now, DirSync has been based on ILM 2007 FP1, which is a functional, but older application, with no x64 support. This means when installing DirSync onto a server, you had to go out of your way to deploy the Windows Server 2008 operating system since the Server 2008 R2 OS is x64 only.

ILM was replaced by Forefront Identity Manager (FIM) 2010, which uses the x64 CPU architecture and as therefore Windows Server 2008 R2 as well.

Today (finally), Microsoft announced DirSync can now be downloaded for use with the 64-bit architecture. This is great news for new Office 365 customers – no more legacy software needed. However, this does raise a question for existing DirSync users: How do we migrate?

You should check out the announcement for details, but essentially, you reformat and rebuild. Wait! Before you start muttering nasty things about Microsoft – the new installation of DirSync will find all of the identities currently in Office 365 and match them up with the appropriate Active Directory accounts in your environment. There is no downtime for the users.

Posted by

Mike Crowley

Posted on

April 7, 2011

Posted under

Windows Server

Comments

RSAT for Windows 7 with Service Pack 1 (SP1)

Until now, there were no Remote Server Administration Tools (RSAT) available for Windows 7 SP1.

Microsoft released an updated version today which adds this support. You can download it here:

Remote Server Administration Tools for Windows 7 with Service Pack 1 (SP1)

Posted by

Mike Crowley

Posted on

February 17, 2011

Posted under

Active Directory

Comments

39 Comments

How to Set Windows 7’s Login Wallpaper with Group Policies

With Windows XP, you could set your own login background colors and/or wallpaper by modifying the values found in the following registry location: [HKEY_USERS\.DEFAULT\Control Panel\Desktop].

Windows 7 no longer reads this registry key. Instead you’ve got to complete the multi-step process described in this article.

While the steps to set a login wallpaper are not complicated, one challenging limitation is the fact your background wallpaper needs to reside on the workstation’s hard drive. Interestingly, this is not true for the user’s wallpaper, as there are GPO settings to point to a network location.

So when I had a customer ask me to set their login wallpaper, I had to think of how I wanted to accomplish their request. We could possibly write a script, and as much “fun” as that might be, I’d rather use something more controlled. Something that would allow me to easily change the configuration later as well as be decipherable to the customer after I leave.

The answer? Group Policy – Preferences, that is!

So before we jump in to the Group Policy Management Console (GPMC), let’s identify what we’re trying to do. If you haven’t already, you may wish to read the above link, otherwise you’re about to be lost.

We want our policy to:

Copy our wallpaper file to the user’s workstation.
Instruct Windows to use our file instead of the default %WinDir%\System32\oobe\background.bmp file.

With the new (ok they aren’t that new anymore) Group Policy Preferences that Windows 7 has built-in, we can copy our wallpaper to the user’s computer, while reserving the right to pull it off if the computer leaves the scope of the GPO. To copy files, open GPMC and follow these steps:

1. Navigate to: Computer Configuration\Preferences\Windows Settings\Files
2. Right-click the “Files” node and select: New > File
3. Select Replace 4. Type in the UNC path for your source file. •In my example I used: \\Srv1\Share\CompanyLogo.jpg •Remember this file needs to be <256K •Also understand the permissions on this share need to allow the workstation’s computer account READ. If you leave the usual “Authenticated Users” you’ll be fine. 5. For the Destination File, type this exact text (without the quotes, and no line breaks): “%windir%\system32\oobe\info\backgrounds\backgrounddefault.jpg”
6. Click the “Common” tab 7. Select “Remove this item when it is no longer applied”. This will ensure your file is removed if: •The GPO is deleted or disabled •The workstation is moved to another OU where the policy is not linked •The policy is filtered out •You update your policy to send a new wallpaper file
8. Optionally: Select Item-level targeting to specify only Windows 7 computers. This will ensure your file isn’t sent to versions of Windows that wouldn’t make use of it anyway.

Now we need to instruct Windows to render this image when the login screen is displayed. If you read the above article, you’ll remember the OEMBackground registry key. The good news is, we don’t need that key because there is actually a setting to enable it in GPMC already.

In the same Group Policy Object, navigate to:

Computer Configuration\Policies\Administrative Templates\System\Logon.

Once there, select “Always use custom logon background” and set it to “Enabled”. This has the same effect of setting the registry manually.

Once you’ve completed these steps, close the Group Policy Management Editor and link your policy to an OU – you’re done!

This policy may take two refresh cycles (e.g. reboots) to take effect. This is because the wallpaper file is not yet present when the “always use custom logon background” setting is first applied. But once the file has completed copying you’ll see your image at logon.

If you would like to consider multiple screen resolutions, please consult this link.

Before we close, I should point out, this can work for Server 2008 R2 as well. I have not tested with Vista or Server 2008.

Finally, here are some geeky, but not too over the top wallpapers: Smile

http://www.jpl.nasa.gov/wallpaper

Posted by

Mike Crowley

Posted on

February 17, 2011

Posted under

Active Directory

Comments

PowerShell Tip – Running a Service Pack Report – Faster

Imagine you wanted to run a quick report of all your server’s service pack level in your domain. After all, SP1 just came out! You could get this information quickly by using the Active Directory Module for Windows PowerShell. If you don’t have at least one Windows 2008 R2 (RTM or SP1) Domain Controller, you could also do something similar with the free Quest PowerShell tools, but that’s for another day…

We can find this information using a few different methods. Here I’ll show two:

Method 1

Get-ADComputer -Properties OperatingSystem, OperatingSystemServicePack -Filter * | Where-Object {$_.OperatingSystem -like '*server*'} |  Format-Table name, oper* -autosize

You can see with Method 1, we’re telling PowerShell to get all the computer accounts from Active Directory. Then we pass those objects over to the “Where-object” cmdlet and ask it to select only those who have an OperatingSystem attribute containing “server”. We then format the results in a table. Give it a try.

Not too shabby; but let’s make it better!

Method2

Get-ADComputer -Properties OperatingSystem, OperatingSystemServicePack -Filter {OperatingSystem -like '*server*'} | Format-Table name, oper* -autosize

In Method 2, we’re making smarter use of the –Filter switch. So instead of getting ALL the computer accounts, we do our filtering up-front. This can lead to significant amount of time saved!

How much time, you ask? Well, we can find out with the “Measure-Command” cmdlet. Just put any command string in {} and it will tell you how long it took to run!

Here are the results from a small environment with fast servers. 677 milliseconds isn’t bad, but when you compare it to 73, you can begin to appreciate the potential.

One last thought: You may wish to add this extra code to make your output prettier. It will organize your results first by operating system and then by name:

Get-ADComputer -Properties OperatingSystem, OperatingSystemServicePack -Filter {OperatingSystem -like '*server*'} | Sort-Object operatingsystem, name | Format-Table name, oper* -autosize

Posted by

Mike Crowley

Posted on

December 14, 2010

Posted under

Active Directory

Comments

6 Comments

Script for Missing UPNs

For various reasons I’ve found myself needing to fix customer sites where the User Principal Name (UPN) was not present for AD user accounts.

Most frequently this is because the environment was once NT4, which did not require this attribute. Whatever the reason, I’ve fixed it using PowerShell.

If you don’t have 2008 R2 domain controllers you can use the free Quest PowerShell add-ins downloaded here.

If you DO have 2008 R2 domain controllers you can use the native Active Directory Module for Windows PowerShell.

Below is a script you can use for either scenario. This will take all users with missing UPNs from the “My Users” OU in the “contoso.local” domain and set their UPN to username@contoso.local

Quest:

Get-QADUser –SearchRoot “contoso.local/My Users” -UserPrincipalName $null -SizeLimit 0 | % {$CompleteUPN = $_.samaccountname +"@contoso.local"; Set-QADUser -Id $_.DN -UserPrincipalName $CompleteUPN}

2008 R2 Native:

Get-ADUser  -Filter {-not (UserPrincipalName -like '*')} -SearchBase 'OU=My Users,DC=contoso,DC=local' | % {$CompleteUPN = $_.SamAccountName + "@contoso.local" ; Set-ADUser -Identity $_.DistinguishedName -UserPrincipalName $CompleteUPN}

Posted by

Mike Crowley

Posted on

June 18, 2010

Posted under

Active Directory

Comments

4 Comments

Released: Active Directory Migration Tool (ADMT) version 3.2

The long awaited 2008 R2 version of ADMT has been released to the web. You can download it here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=20C0DB45-DB16-4D10-99F2-539B7277CCDB&displaylang=en

A good read, if you’re looking at using this tool is:

Active Directory Migration Guide

Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains

However for complex migrations/transitions/whatever I prefer the Quest Migration Manager for Active directory.

Here is some info from the ADMT download page:

The Active Directory Migration Tool version 3.2 (ADMT v3.2) provides an integrated toolset to facilitate migration and restructuring tasks in an Active Directory Domain Services infrastructure.

Overview

The Active Directory Migration Tool version 3.2 (ADMT v3.2) simplifies the process of migrating objects and restructuring tasks in an Active Directory® Domain Service (AD DS) environment. You can use ADMT v3.2 to migrate users, groups, service accounts, and computers between AD DS domains in different forests (inter-forest migration) or between AD DS domains in the same forest (intra-forest migration). ADMT can also perform security translation (to migrate local user profiles) when performing inter-forest migrations.

System Requirements

Supported Operating Systems: Windows Server 2008 R2

ADMT can be installed on any computer capable of running the Windows Server 2008 R2 operating system, unless they are Read-Only domain controllers or in a Server Core configuration.

Target domain: The target domain must be running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2

Source domain: The source domain must be running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2

The ADMT agent, installed by ADMT on computers in the source domains, can operate on computers running Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

Additional Information

PES v3.1 is a separate download also available on the Microsoft Download Center. See the Related Downloads section below.

ADMT v3.2 is the last version of the tool which will support migration operations involving Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2 source domains, target domains, or domain controllers.

To obtain customer support if you are performing migration operations involving NT 4.0 (with SP4 or higher) or Windows 2000 Server source domains, or domain controllers, please contact your Microsoft Services representative or visit http://www.microsoft.com/microsoftservices.

Mike Crowley's Whiteboard

“There are no limits to what you can accomplish when you are supposed to be doing something else."

Tag Archives: ActiveDirectory

What are the Azure DirSync Cmdlets [Updated]?

Backup and Restore Instructions for the DirSync Database

DirSync 1.0.6593.0012

DirSync 1.0.6567.0018 Has Been Released

Upgrading DirSync to the Latest Version

Converting SMTP Proxy Addresses to Lowercase

Combining PowerShell Cmdlet Results

Office 365 DirSync (x64) Installation Walkthrough

A New Version Of Office 365’s Directory Synchronization Tool Has Arrived!

RSAT for Windows 7 with Service Pack 1 (SP1)

PowerShell Tip – Running a Service Pack Report – Faster

Script for Missing UPNs

Released: Active Directory Migration Tool (ADMT) version 3.2

Overview

System Requirements

Additional Information