Logo 
Search:

MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

Userprofile import...when to do that?

  Asked By: Holly    Date: Jan 11    Category: MOSS    Views: 1499

We'd like to eventually use the mysite feature and people search. To do
that, we'll want to bring over the user profiles from peoplesoft...which
is currently be maintained by another agency. We're going to look into
options for that.

My question is if there is any advantage to getting this done first
before we build any other team collaboration sites (not mysites) or can
we just wait and bring the user profiles over down the road when we're
ready to turn on mysites?

Share: 

 

7 Answers Found

 
Answer #1    Answered By: Dameon Dejesus     Answered On: Jan 11

Profiles are used for audiences, people  search, and replicating
properties (such as username, desk phone, bldg, etc) to site
collections.

I would do it now. But, if you will eventually use AD as your identity
manager, then I might blow them away when you make the switch and
re-import. Otherwise, the unique id must be the same on both systems or
you will get duplicate profiles.

 
Answer #2    Answered By: Tejaswani Barve     Answered On: Jan 11

Another option is to possibly have your Active Directory data
populated from your peoplesoft  database by using MIIS - Microsoft
Identity Integration Server

Then get your user  profile populated from your AD source. A good
advantage of keeping your AD source uptodate is the user presence
smart tag will have correct info in the MOSS environment.

 
Answer #3    Answered By: Harshita Padwal     Answered On: Jan 11

> I would do it now. But, if you will eventually use AD as your identity
> manager, then I might blow them away when you make the switch and
> re-import. Otherwise, the unique id must be the same on both systems
or
> you will get duplicate profiles.

Well, we're using AD for authentication. Not sure what identity manager
refers to, though. Seems we have authentication and we have profile
data. How are those two resolved within MOSS?

> Another option is to possibly have your Active Directory data
populated
> from your peoplesoft  database by using MIIS - Microsoft Identity
Integration Server

I don't think there's any interest by our AD folks to do that, though I
can certainly look into that.

What I'm confused about is if one is using AD authentication, how does
that relate to MOSS's own user  profiles? Should user profiles  be
populated from the same data as is being used for authentication?

Our issue is that AD isn't always up to date...it might have outdated
titles, phone numbers, etc. Not ideal, of course, but out of my realm.
Our finance data stored in Peoplesoft is more accurate, hence us wanting
to try and grab that data directly.

 
Answer #4    Answered By: Jennifer Jones     Answered On: Jan 11

First, authentication and profiles  are different. Profiles are a way to
find out information about somebody, whether they are an authenticated
user or not. But, with correctly configured profiles and the
'replicable' property value, we can expose any number of properties
about a person from their profile (matches SID in profile with SID in
authenticated user, I think). This is very cool...

Second, if you are using Peoplesoft for profile data, and AD for
authentication, you probably have to import  from both sources to get a
complete profile... not sure, now that I type this. I would guess you
will need to import from both sources, but carefully define your profile
properties such that 'username attribute' matches between both
PeopleSoft and AD, or you will get dupes. Let us know how it goes.

 
Answer #5    Answered By: Annie Norris     Answered On: Jan 11

> First, authentication and profiles  are different.

Great. I was on the right track with that thinking then.

user  or not. But, with correctly configured profiles and the
> 'replicable' property value, we can expose any number of properties
> about a person from their profile (matches SID in profile with SID in
> authenticated user, I think). This is very cool...

So, what uses that connection? Does that come into play when using
profile targeting of content?

I think the profile feature  is something we're just going to have to get
used to as we've never had that option before. It'll probably make more
sense once we start using it.

> Second, if you are using Peoplesoft for profile data, and AD for
> authentication, you probably have to import  from both sources to get a
> complete profile... not sure, now that I type this. I would guess you
> will need to import from both sources, but carefully define your
> profile
> properties such that 'username attribute' matches between both
> PeopleSoft and AD, or you will get dupes. Let us know how it goes.

 
Answer #6    Answered By: Chadd Hahn     Answered On: Jan 11

IMO, the easiest way to understand MOSS profiles  and AD is to look at the
user profiles and Profile Properties pages in the Shared Services Admin
(assuming you have rights to that). You'll find it at:
http://server:port/ssp/admin/_layouts/MgrProperty.aspx

This lists the properties that Sharepoint uses for a person's profile. Some
of the items, like Interests or Hire Date, can be deleted if they aren't
relevant to your needs. Others, like SID and First name, are required.
Looking at the "Mapped Attribute" column, you can see some of the default
mappings to AD that Sharepoint uses. So the "First name" in a Sharepoint
profile is mapped to the "givenName" in AD.

Selecting "edit" on a property in that Profile Property page gives you the
various settings available for that property, including "Property Import
Mapping" at the bottom. The ones that are already mapped will default to the
"Master Connection" source data connection, but looking through them you'll
see that you can change the data source for some of them. AFAIK though, some
items like the account name are required to come from the default AD source
for the SSP. (It would be a useful blog post to verify and itemize these.)

Something else to be aware of is that Sharepoint profile properties can be
set to be editable by the Sharepoint user, but if that item is also mapped
to an import  source, those modifications will be overwritten on the next
import.

Defining authoritative sources of user  information is a sisyphean battle, in
my experience. And IT likes to create redundant user information
repositories like bunnies...like to make more bunnies. Like you, we have AD
and PeopleSoft. We also have a couple linux based LDAP repositories, Novell
somethingorother for some lans, as well as various custom databases. We've
been working to consolidate what we can, but it seems like every new system
or software product wants to create a new user database.

I like Mohit's suggestion of populating AD with some of the PeopleSoft data.
I've also been reading up on ADFS to see where that might help. Might be
worth looking into.

 
Answer #7    Answered By: Cheryl Kelley     Answered On: Jan 11

This is very helpful and very clear. We are working on
getting the user  profile as edited by the user in MySite propagated to all
the other various SSP's on our campus. " Property Import Mapping" might
well be the ticket.

You might find it helpful to read up on MIIS as well as ADFS. Microsoft
Identity Integration Server is a product that draws identity-related
information from providers and provisions it to consuming systems. If you
have "n" providers and "m" consumers, MIIS reduces the interface complexity
from n times m to n plus m. I don't think we're moving toward fewer
"bunnies", but maybe we can do better at keeping them on the same page.

 
Didn't find what you were looking for? Find more on Userprofile import...when to do that? Or get search suggestion and latest updates.




Tagged: