I like to save the configuration of the FIM Synchronization Service from time to time; whether it is before patching, to move the configuration to a test/production environment or for any other reason.
For that purpose, I've created a script that will help get the configuration exported quickly and easily. I do love Powershell, so the script is of course written in Powershell and makes use of some out-of-the-box CLI tools like srvexport.exe and maexport.exe (the path for these utilities are hardcoded in the script, so you may want to change these if your installation doesn't use the default installation path for FIM Synchronization Service).
You can download the script here
The script does not export the encryption key, so remember to do that as needed.
Sunday, September 30, 2012
Monday, September 24, 2012
Codeless provisioning with FIM?
So you want to do codeless provisioning with FIM? No problem you just go ahead and use the built-in features of Synchronization Rules. However, if you don't want to use Synchronization Rules for whatever reason, you may want to take a look at FIM Metaverse Rules Extension (FIM.MRE).
It's basically a framework that's I've been evolving over time (since MIIS/ILM) and now decided to release for public use with FIM. Basically, it allows you to do provisioning in the FIM Synchronization Service without using Synchronization Rules (SR's). You could, of course, combine this framework with SR's and built a great synchronization solution with the two playing together side-by-side.
There is an initial version 1.0 of FIM.MRE out with documentation (you can find it here http://blog.goverco.com/p/fim-provisioning-framework-fim-mre.html). Documentation and code will evolve as I expand it for my upcoming FIM projects and I'll try to release in regular cycles. It is already being used at some of my customers and more will probably adopt it in the near future.
So, give it a go and let me know what you think. And please feel free to leave suggestions and comments on the page to encourage further development.
It's basically a framework that's I've been evolving over time (since MIIS/ILM) and now decided to release for public use with FIM. Basically, it allows you to do provisioning in the FIM Synchronization Service without using Synchronization Rules (SR's). You could, of course, combine this framework with SR's and built a great synchronization solution with the two playing together side-by-side.
There is an initial version 1.0 of FIM.MRE out with documentation (you can find it here http://blog.goverco.com/p/fim-provisioning-framework-fim-mre.html). Documentation and code will evolve as I expand it for my upcoming FIM projects and I'll try to release in regular cycles. It is already being used at some of my customers and more will probably adopt it in the near future.
So, give it a go and let me know what you think. And please feel free to leave suggestions and comments on the page to encourage further development.
Sunday, September 23, 2012
Small update for MARunScheduler
It clearly does make a difference if you, like Jorge, support and comment.
He left a few suggestions for future versions of the MARunScheduler on the official page and that triggered me into to adding one of his suggestions.
So now there is a small update to the MARunScheduler. The update (version 1.2.0.0) includes options to specify which weekdays a thread or an item should be active. Also, a little bug on Clear Run History was fixed.
And please, consider following Jorge' example and share your thoughts on the product. You can see more on how to support this product on the official page and get your copy of latest version of MARunScheduler.
He left a few suggestions for future versions of the MARunScheduler on the official page and that triggered me into to adding one of his suggestions.
So now there is a small update to the MARunScheduler. The update (version 1.2.0.0) includes options to specify which weekdays a thread or an item should be active. Also, a little bug on Clear Run History was fixed.
And please, consider following Jorge' example and share your thoughts on the product. You can see more on how to support this product on the official page and get your copy of latest version of MARunScheduler.
Sunday, September 16, 2012
The 'Microsoft Forefront Identity Manager 2010 R2 Handbook'
I was given the chance to read through the "Microsoft Forefront Identity Manager 2010 R2 Handbook" only when it was fresh out of the press.
And after many years of doing ILM/FIM projects, I must say that this book is a great reference for system administrators seeking a deep and highly technical knowledge of Forefront Identity Manager 2010 R2 and all its many facets.
Forefront Identity Manager 2010 R2 (or FIM) is a very big product. Too truly master it, you have to have a solid amount of experience with infrastructure (not only Microsoft) and also understand processes around the life cycle of users, groups and other objects in complex infrastructures and organizations.
When doing FIM implementations is nice to "have something to hold on too" - a reference and maybe starting point. And this book is just that. The title of the book 'Microsoft Forefront Identity Manager R2 Handbook" is spot on. Kent has written a book that you truly can use for the many different aspects of a FIM implementation - ranging from the installation process itself all the way to administering and maintaining the system in production. And its a book that you can come back to for thoughts on "how to".
Reading through the book, you really get the feeling that it is thought through and it is based on many years of real life experience and the troubleshooting section of the book proves just that. The book is comprehensive and covers all the features of the product, including Certificate Management, which you don't see covered in writing very often. This book does a really good job of showing good, practical examples on how to actually configure FIM with different systems, i.e.Exchange and Lync and gives you an idea on how to crunch "strange" input data, a thing, that you are very likely to run into in real FIM deployments.
All this is done in a way that you potentially (with a few modification, of course) could apply in a production environment.
The book feels well-structured and has a good flow. But you can also use it as a "goto"-guide for the different aspects of FIM. It is a must-have for those wanting to engage with FIM.
Don't get it only for the technical stuff but also for the vast real life knowledge that Kent has surely put into it.
This book can really support those that wants "to get FIM".
Enjoy it!
FYI: You can get the book here.
Wednesday, September 12, 2012
Nifty little logging function for .NET code
This is not directly related to FIM 2010, but thought I'd share it anyway.
Whenever I write some code (workflows, Management Agents or such), I like to add a little logging. Usually I make sure that it can be switched on and off through a registry key.
In the log, it's nice if you can see just where in the code processing is taking place. Instead of hard coding function names, I use the little function below to get me a string of the current function names.
public static string GetEntryPointName()
{
StackTrace trace = new StackTrace();
int index = 0;
string str = null;
for (index = trace.FrameCount - 2; index >= 2; index += -1)
{
if (str != null)
{
str = str + "->";
}
str = str + trace.GetFrame(index).GetMethod().Name;
}
trace = null;
return str;
}
You'll need to include System.Diagnostics to use the StackTrace method.
Throughout my code, I now just put something similar to this -
Log(string.Format("{0}: {1}", GetEntryPointName(), logMessage);
The output in the logging is similar to this (this is a snippet from a log file for my PowerShell Management Agent) -
InvokeBeginImportWorker->OpenImportConnection->Log InvokeBeginImportWorker->OpenImportConnection: Enter
InvokeBeginImportWorker->OpenImportConnection Getting schema
InvokeBeginImportWorker->OpenImportConnection Type: user
InvokeBeginImportWorker->OpenImportConnection Anchor attribute: objectGuid
InvokeBeginImportWorker->OpenImportConnection Attribute: objectSid
InvokeBeginImportWorker->OpenImportConnection Attribute: homeDirectory
InvokeBeginImportWorker->OpenImportConnection Attribute: sAMAccountName
InvokeBeginImportWorker->OpenImportConnection Attribute: sn
InvokeBeginImportWorker->OpenImportConnection Attribute: givenName
InvokeBeginImportWorker->OpenImportConnection Attribute: objectGuid
InvokeBeginImportWorker->OpenImportConnection Attribute: displayName
InvokeBeginImportWorker->OpenImportConnection Got schema
InvokeBeginImportWorker->OpenImportConnection->InitializeConfigParameters->Log InvokeBeginImportWorker->OpenImportConnection->InitializeConfigParameters: Enter
Now, go log your pants off...
Whenever I write some code (workflows, Management Agents or such), I like to add a little logging. Usually I make sure that it can be switched on and off through a registry key.
In the log, it's nice if you can see just where in the code processing is taking place. Instead of hard coding function names, I use the little function below to get me a string of the current function names.
public static string GetEntryPointName()
{
StackTrace trace = new StackTrace();
int index = 0;
string str = null;
for (index = trace.FrameCount - 2; index >= 2; index += -1)
{
if (str != null)
{
str = str + "->";
}
str = str + trace.GetFrame(index).GetMethod().Name;
}
trace = null;
return str;
}
You'll need to include System.Diagnostics to use the StackTrace method.
Throughout my code, I now just put something similar to this -
Log(string.Format("{0}: {1}", GetEntryPointName(), logMessage);
The output in the logging is similar to this (this is a snippet from a log file for my PowerShell Management Agent) -
InvokeBeginImportWorker->OpenImportConnection->Log InvokeBeginImportWorker->OpenImportConnection: Enter
InvokeBeginImportWorker->OpenImportConnection Getting schema
InvokeBeginImportWorker->OpenImportConnection Type: user
InvokeBeginImportWorker->OpenImportConnection Anchor attribute: objectGuid
InvokeBeginImportWorker->OpenImportConnection Attribute: objectSid
InvokeBeginImportWorker->OpenImportConnection Attribute: homeDirectory
InvokeBeginImportWorker->OpenImportConnection Attribute: sAMAccountName
InvokeBeginImportWorker->OpenImportConnection Attribute: sn
InvokeBeginImportWorker->OpenImportConnection Attribute: givenName
InvokeBeginImportWorker->OpenImportConnection Attribute: objectGuid
InvokeBeginImportWorker->OpenImportConnection Attribute: displayName
InvokeBeginImportWorker->OpenImportConnection Got schema
InvokeBeginImportWorker->OpenImportConnection->InitializeConfigParameters->Log InvokeBeginImportWorker->OpenImportConnection->InitializeConfigParameters: Enter
Now, go log your pants off...
Thursday, September 6, 2012
New version of MARunScheduler
Along with the online version of the manual for MARunScheduler, I've also released a new version of the product.
The version includes new options for more granular scheduling. You can find the download in the last part of the manual, which can be found here.
The version includes new options for more granular scheduling. You can find the download in the last part of the manual, which can be found here.
Monday, September 3, 2012
Password Registration URL in FIM Portal
Recently, I've had a customer ask the question and I've also seen a few similar questions in the FIM 2010 forum.
How do I change the URL for the 'Register for password reset' link in the portal?
If you look at the default link in the FIM portal, it just says 'javascript:PwdRegister()', so changing it through the administrative settings in the portal does seem to do the trick - although I have seen some clever javascript typed into the "Home Page Resources" under the "Administration" menu and selected "Register for password reset" where the default setting was changed to javascript:void(window.open('http://servername:port/default.aspx'));
Though this might work, I'm not sure if this is actually supported; so I dug a little deeper to figure out exactly where the default 'javascript:PwdRegister()' gets it's URL from.
It seems that it actually reads from the registry under the hive HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Forefront Identity Manager\2010\Portal and there it reads the value of the key 'RegistrationPortalUrl'. The proper way to change this would certainly be to go through the Setup program for FIM, but if you need to change this without going through the setup again, you could change this value in the registry. And you won't have to fiddle around with javascripting.
Please note that you need to do an IIS Reset after changing the value.
How do I change the URL for the 'Register for password reset' link in the portal?
If you look at the default link in the FIM portal, it just says 'javascript:PwdRegister()', so changing it through the administrative settings in the portal does seem to do the trick - although I have seen some clever javascript typed into the "Home Page Resources" under the "Administration" menu and selected "Register for password reset" where the default setting was changed to javascript:void(window.open('http://servername:port/default.aspx'));
Though this might work, I'm not sure if this is actually supported; so I dug a little deeper to figure out exactly where the default 'javascript:PwdRegister()' gets it's URL from.
It seems that it actually reads from the registry under the hive HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Forefront Identity Manager\2010\Portal and there it reads the value of the key 'RegistrationPortalUrl'. The proper way to change this would certainly be to go through the Setup program for FIM, but if you need to change this without going through the setup again, you could change this value in the registry. And you won't have to fiddle around with javascripting.
Please note that you need to do an IIS Reset after changing the value.
Subscribe to:
Posts (Atom)