Very helpfull when eliminating errors in FIM in bulk.
Identity Trench: In Search of Export-Not-Reimported Errors
torsdag den 13. juni 2013
tirsdag den 11. juni 2013
The type initializer for 'Microsoft.Exchange.Diagnostics.ExTraceConfiguration' threw an exception.
I am currently working on a migration project. My company is migrating from Lotus Notes to Microsoft Exchange/Office 365.
We are currently in a POC where all Notes mailusers have have been created in AD as Contacts. My task is to convert the Contact objects to mailenabled AD users.
Since the mechanism for converting Notes users to Contacts is pretty messy and unreliable, I use my favorite tool (Powershell, if you should wonder) to retrieve the correct information directly from Notes. I use a variant of a custom cmdlet described earlier in my blog.
I need a live connection to the Exchange server to Mail-enable the AD users once they have the correct proxyaddresses and targetaddress. The AD stuff is done by importing the activedirectory module.
Everything worked fine in development, but once combined to a final script, the console became strangely buggy after running the script. Ordianry stuf like ping gave no results, and the get-help cmdlet stopped working.
I could live with that, since the script should run scheduled and the console would be closed after each run.
The I upgraded to Powershell 3.0.
In Powershell 3.0 the script no longer stuck to making the console buggy. In stead Powershell crashed with this dialog box:
and this console output:
The type initializer for 'Microsoft.Exchange.Diagnostics.ExTraceConfiguration' threw an exception.
+ CategoryInfo : OperationStopped: (MyExchangeServer.MyDomain.dk:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : JobFailure
+ PSComputerName : MyExchangeServer.MyDomain.dk
The funny thing was, that the script continued and did, what it was supposed to do, until the "Close program" button was pressed.
I could have lived with that, but unfortunately the Task Scheduler is polite and presses the "Close program" button as soon as it sees it, so I had to figure out, what causes the problem.
Several hours of bug tracking later, it turns out to the order in which the cmdlets loaded are used - or so I thought.
The original setup, that causes the error is like this:
. 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'
Connect-ExchangeServer -auto
Get-ADUser <Samaccountname>
Get-MailUser <Samaccountname>
To make it work without failing I added this:
. 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'
Connect-ExchangeServer -auto
Get-Mailuser StupidExchangeBug
Get-ADUser <Samaccountname>
Get-MailUser <Samaccountname>
And gone was the error!
Just to get rid of the nasty red when running Get-Mailuser StupidExchangeBug, which does not look nice in the transcript file, I added -ErrorAction silentlycontinue, and rescheduled the task.
This morning at the office i looked at my task and was quite surprised to see, that the task had failed. I ran the script in the console and the annoying messagebox popped up again - script still running and doing its thing. DANG!
This time the bug tracking was cut down to removing the erroraction switch and the error disappeared again.
Please feel free to test this yourself by running the above described commands. The shell crashes, if you are on PS 3.0 so please run "Powershell -noprofile" before entering the code, unless you don't care about your console ;-)
We are currently in a POC where all Notes mailusers have have been created in AD as Contacts. My task is to convert the Contact objects to mailenabled AD users.
Since the mechanism for converting Notes users to Contacts is pretty messy and unreliable, I use my favorite tool (Powershell, if you should wonder) to retrieve the correct information directly from Notes. I use a variant of a custom cmdlet described earlier in my blog.
I need a live connection to the Exchange server to Mail-enable the AD users once they have the correct proxyaddresses and targetaddress. The AD stuff is done by importing the activedirectory module.
Everything worked fine in development, but once combined to a final script, the console became strangely buggy after running the script. Ordianry stuf like ping gave no results, and the get-help cmdlet stopped working.
I could live with that, since the script should run scheduled and the console would be closed after each run.
The I upgraded to Powershell 3.0.
In Powershell 3.0 the script no longer stuck to making the console buggy. In stead Powershell crashed with this dialog box:
and this console output:
The type initializer for 'Microsoft.Exchange.Diagnostics.ExTraceConfiguration' threw an exception.
+ CategoryInfo : OperationStopped: (MyExchangeServer.MyDomain.dk:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : JobFailure
+ PSComputerName : MyExchangeServer.MyDomain.dk
The funny thing was, that the script continued and did, what it was supposed to do, until the "Close program" button was pressed.
I could have lived with that, but unfortunately the Task Scheduler is polite and presses the "Close program" button as soon as it sees it, so I had to figure out, what causes the problem.
Several hours of bug tracking later, it turns out to the order in which the cmdlets loaded are used - or so I thought.
The original setup, that causes the error is like this:
. 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'
Connect-ExchangeServer -auto
Get-ADUser <Samaccountname>
Get-MailUser <Samaccountname>
To make it work without failing I added this:
. 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'
Connect-ExchangeServer -auto
Get-Mailuser StupidExchangeBug
Get-ADUser <Samaccountname>
Get-MailUser <Samaccountname>
And gone was the error!
Just to get rid of the nasty red when running Get-Mailuser StupidExchangeBug, which does not look nice in the transcript file, I added -ErrorAction silentlycontinue, and rescheduled the task.
This morning at the office i looked at my task and was quite surprised to see, that the task had failed. I ran the script in the console and the annoying messagebox popped up again - script still running and doing its thing. DANG!
This time the bug tracking was cut down to removing the erroraction switch and the error disappeared again.
Please feel free to test this yourself by running the above described commands. The shell crashes, if you are on PS 3.0 so please run "Powershell -noprofile" before entering the code, unless you don't care about your console ;-)
Abonner på:
Opslag (Atom)