I recently was RDP’d into a server and from there had RDP’d to another server.
Using the standard CTL+ALT+END to get to the login screen didn’t work.
I had been connecting by just using the Accesstories–>Remote Desktop Connection and clicking OK since the server was already in the history. This would take me through a credentials box which logged me into the server as it connected.
To fix this, I created a remote desktop connection without any user credentials–just using a value in the Computer of the General tab, but not entering a user. (Click the Options button on the Remote Desktop Connection start screen.) This avoided the Window pop up style login.
I kind of feel like a tool for how elementary this seems now, but figured I’ll either forget it or maybe it’ll help someone in the future.
When working with the AddSidHistory call, I was getting this error. I was stumped as I had followed all of the permissions required for the account running the script. (These are all documented in the clonepr.doc.)
It turns out it was one or possibly two things:
1. For some reason, the delegate control for “Migrate SID” wasn’t on one of the OUs, even though I’d granted it at root level. (Probably a user error there as it was late in the day.)
2. This was a lab environment and I thought I was working off of PDCs, but nope. Turns out there were PDCs hidden from me.
In total, here are the permissions I granted the service account:
– delegate control to migrate SIDs.
– Administrator member on source domain and Domain Admin on target domain.
– Create the target group domainName = “$$$” to hold users having their SIDs migrated. (Don’t put the users in there, the code will do that for you.)
– Granted the service account Full Control over the target OU and Read over the source OU. (This may be overkill…And I’d think adding the user to Domain Admins should do taht anyway, but the client has a complex AD security structure.)
– Enabled the event logging for changes to SIDs via the Account Management option in Local POlicies (clonepr.doc has the steps to do this).
– Ran the script on the target PDC.
Hope that helps someone.
I was getting this error (remote procedure call failed 0x800706BE) when doing a sync on any of the management agents except the FIM MA.
I have custom rules extensions for all of my management agents except FIM MA and they all rely on one Utils.dll I wrote.
It turns out there was an error in one of the methods in the Utils.dll and, because I had turned off my debugging feature, I wasn’t getting any other information about the error. Reverting to an older version of the dll fixed the problem.
I was running into an issue where I had set a host header for a SharePoint site, but was unable to authenticate. I’d get prompted for credentials three times and then receive a 401 error. (The site worked with the computername and ip address.)
This registry change for BackConnectionHostNames fixed the issue for me: http://support.microsoft.com/kb/896861
I need to read up a bit more on what that is actually doing to be sure it’s OK for our needs though.
In a lab environment, I wasn’t able to access the password registration portal from any server other than the FIM portal server. Turns out, I’d missed setting the SPN for the HTTP/Password Registration and Reset portals.
While installing reporting for FIM, I left the management packs deploying overnight. To my surprise, they weren’t finished this morning. (I know it takes a while, but not THAT long.)
Checking the Event Viewer “Operations Manager” log on the data warehouse server revealed that there was a problem starting the Health Service.
Starting the System Center Management service (which was, indeed, in a stopped state) seems to have cleared up the issue.
Microsoft Support had me set FIM into single request mode to get around an issue in the Beta version of R2. I had to ask for instructions, so thought I’d post them here for future reference:
“There is configuration file for sync service:
C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin\miiserver.exe.config
You will have to change default value for “aggregate” attribute of “resourceSynchronizationClient” section to “false”.
Basically, if you haven’t modified this file before and everything is default, then your “resourceSynchronizationClient” node will change from this:
After you make this change you will have to close “Synchronization Service Manager” and restart the “Forefront Identity Manager Synchronization Service”. Once it is done you’re switched to single request mode for synchronization.”
When I tried to access the password registration site from the FIM portal home page, I received this error:
“Password reset registration cannot be completed because configuration data are missing from this computer.”
There was nothing in the Event Viewer.
Not sure if this is the correct approach, but I went to “Home Page Resources” under the “Administration” menu and selected “Register for password reset”. I changed the Navigation Url in the Behavior tab to:
That seemed to work.
So, I could login to my new SharePoint site with the Administrator account when I was logged into the server, but not when logged into another machine.
I was able to pull up Central Administration from the other machine.
After much puzzling, it looks like the SharePoint service account for my site isn’t correctly configured. When I switched the service account to the same one Central Administration is using, I could log in just fine.
Turns out the service account hadn’t had the SPNs set:
setspn -s HTTP/FIMServerName domain\SPService
setspn -s HTTP/FIMServerName.domain.com domain\SPService
setspn -s FIMService/FIMServerName domain\FIMService
setspn -s FIMService/FIMServerName.domain.com domain\FIMService
I was receving the above error and FIM would roll back the installation.
I’m not sure what finally fixed it, but the possibilities are:
1. Allowed FIM to create it’s own cert.
2. Re-ran the MPSyncJobs and made sure they were all finished before trying to install FIM Reporting again.