I’ve been using CSV files with FIM File-based MA’s now and then and till now I never had any issues. This week I received a new CSV and I had issues getting the configuration of the MA right. To be more precise, whenever I ran a Full Import I got an error stating stopped-file-embedded-nulls. I asked the guys why they put those nulls in the CSV… They had no clue :). They did some PowerShell magic and used the import-csv and export-csv commandlets to generate the CSV.

The error in the Synchronization Manager:

In the event log:

In words: The management agent “MA NAME” failed on run profile “Run Profile Name” because null characters were embedded in the input file. User Action Verify the input file and the code page configuration for the management agent.

After some googling and reading about embedded nulls I opened the CSV using some binary file viewer:

At the begin of the file you can see FF FE which is definitely not supposed to be there. If we simply open the file with notepad, copy paste the contents into a new file, the FF FE values are gone in the resulting file and the import runs just fine. That’s a good workaround for once, but it’s not acceptable to do on a regular base. And it’s sure as hell isn’t a nice answer as to why these symbols are being added by PowerShell!

Some more googling led me to: PowerShell Byte Array And Hex Functions which says:  The “0xFF,0xFE” bytes at the beginning of a Unicode text file are byte order marks to indicate the use of little-endian UTF-16. Now that ringed a bell!

My MA had “Western European” as Code page (default): This can be found on the Configure Attributes tab of the File MA configuration.

By clicking change we can choose “Unicode”, which I think is the equivalent of “little-endian UTF-16”.

Either way, running a full import now succeeds just fine!

[Update] As the comment system seems to have acted up both Brian Desmond and Carol Wapshere mailed me and pointed me to the fact that you can just append the “-encoding ASCII” to the export-csv commandlet to avoid the above issue in the first place. Thanks for the tip both of you!

A screenshot of the help section of the export-csv commandlet:

In my current project I have an AD MA which is configured to provision for Exchange 2010. My customer has multiple Hub/CAS servers load balanced by a hardware solution. At first I provided a specific server in the Exchange 2010 RPS URI in the AD MA. Once the Exchange guys implemented the changes to Kerberos-enable the CAS array, I switched over to a virtual name. In our lab environment this worked just fine, however in the acceptance environment I kept receiving “ma-extension-error”:

This blocked all exports on the AD MA. In the  application event log the following error is show:

In text:

The most obvious thing to do at this time is to start googling. A very promising link is the Troubleshooting the Exchange Management Shell The above error could be caused by Release Candidate version PowerShell binaries. Well that’s definitely not the case. Using the following PowerShell commands I was able to reproduce the issue from the Synchronization Server:

• $user = Get-Credential
• $session = New-PSSession -configurationname microsoft.exchange -connectionuri http://virtualurl.demo.com/powershell -credential $user
• Enter-PSSession $session

Which gave me the following output:

Enter-PSSession : Starting a command on remote server failed with the following error message : The Windows Remote Shell cannot process the request; the selector value 962F626B-6492-493B-BF42-772C7C6BAFBD specified in the request was not found. For more information, see the about_Remote_Troubleshooting Help topic.

At line:1 char:16

+ Enter-PSSession <<<< $session
+ CategoryInfo : ResourceUnavailable: (:) [Enter-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : System.Management.Automation.Remoting.PSRemotingDataStructureException,
Microsoft.PowerShell.Commands.EnterPSSessionCommand

So using netsh I started tracing and soon I saw the light, whereas we asked the networking guys to implement IP Affinity for the load balanced name, they seemed to have forgotten to actually do this… Hence the PowerShell session is being created with one server in the farm, whilst the actual command is probably being sent to another server… Not good!

Conclusion: Whenever you configure a load balancing solution for the Exchange 2010 CAS role, make sure you configure your solution to redirect sessions from the same IP to the same CAS node in the farm. This definitely seems to be a requirement for remote PowerShelling.

I’ve been working with FIM quit a bit, but I never got involved with workflows. Today I saw something passing the FIM forums which I thought is worth blogging about. If it’s no use for you, it will be for me to find it back afterwards anyhow. One of the things with user account creation is the password generation/communication process. Using the FIM declarative provisioning it’s quit straight forward to get a random password generated and flow that out to AD. On the other hand, it would be pretty neat if at the same time the manager for the new employee gets a mail with the username/password. In order to accomplish this you can follow the following steps:

The easiest way to solve this is by using one SR and three activities in an action workflow.

The SR: On the workflow tab on the SR designer, create a parameter called InitialPassword. On the outbound flow tab, map this parameter to the unicode password attribute. The use of a workflow parameter will tell the SR that this value will be calculated in a workflow and passed in by the SR activity.

Activity 1: Function activity to generate a random password
E.g.

Target: [//WorkflowData/Password]
Source: "Pass" + RandomNum(1000,9999) + "word" (This will generate a 12 char password)

Activity 2: SR activity
Select to add the SR. The InitialPassword parameter from the SR is visible. Set its value to [//WorkflowData/Password]

Activity 3: Email activity
Craft an email. Where you want the initial password to appear you enter [//WorkflowData/Password].
All you need now is an MPR and a set to trigger this workflow.

This is just a copy-paste of Andreas Kjellman in Sending user's details in mail

Thanks to Markus for bringing it up: Random password and FIM

This is going to be a short one: believe it or not, but there’s an alternative to installing Wireshark (or at least winpcap) on all your servers when troubleshooting network related issues. It actually has been out there ever since Windows 7 and Windows 2008 R2 came out. Using “netsh trace start capture=yes” you can start capturing network traffic. Simply execute “netsh trace stop” whenever you are ready. The result is an .etl file you can open using network monitor 3.2 or later. Awesome #1: no need to install anything!

But it doesn’t stops there: using “netsh trace start capture=yes persistent=yes” tracing will even continue after a reboot. So as soon as the network interface starts communicating, traffic will be captured! Awesome #2: capturing information during the boot process of a server!

Some screenshots:

Some additional information to get you started: http://blogs.technet.com/b/netmon/archive/2009/05/13/event-tracing-for-windows-and-network-monitor.aspx

But it doesn’t stops here! IE 9, currently in beta, has a new addition too: a built-in network trace utility! In fact it provides (some?) of the functionality Fiddler provides. I am not that experienced with Fiddler, so I don’t know how to compare them feature-wise, but It’s definitely useful having this built-in. Checking it out for sure!

To start using it: Press F12 –> Network –> Start Capturing

P.S. I am by no means saying you should ditch Wireshark/ Fiddler for Netsh Trace/ IE 9 network tracing.  But I think they are great tools to have in your toolbox!

Happy Tracing, Happy New Year!
Thomas