Recursos para Profesionales de TI >
Página principal de foros
>
SharePoint - Social Computing (pre-SharePoint 2010)
>
MOSS MySites
MOSS MySites
- We are currently running WSS and are due to switch to MOSS later this year. I have heard people mention "MySites" before, but I really want an end-user take on exactly what they are and what they are used for in the business world.
One main thing I want to focus on is the ability to store contact information. How is this information collected and stored on a MySite? Currently, our contact information on employees is sparse, and it has been my project to look into what kind of things we could do to maintain contact information. We are looking not only to have first name, last name, office phone, but also to have fields like manager's name, mentor's name, etc. Are there ways to customize the type of contact information stored? How easy is this to maintain? Is maintenance done on a personal level or can we have someone in charge of all contact information?- CambiadoMike Walsh MVPMVP, Moderadorjueves, 02 de julio de 2009 14:30MySite q (From:SharePoint - General Question and Answers and Discussion)
Respuestas
- The my site contact information is fetched from the (MOSS) user profile and can be centrally maintained by someone or by the user itself. It is customizable (you can add your own variable, like mentor, language,...) and specify the visibility level of the information (who can see what : you manager, your colleagues,...).
More details here ("MOSS User Profile Info - How the information flows").
Serge Luca; blog: http://www.redwood.be- Marcado como respuestaSP Brian lunes, 06 de julio de 2009 15:50
- The SSP and the Proile is a pretty rich feature set. Setting up "standard" imports is very quick and easy with all of the standard fields pre-mapped for you. It shouldn't take more than 10-15 minutes to set it up. The import time varies based on a number of factors including the number of people, network structure, etc. I haven't done one with more than 20k accounts before, but I can't imagine it taking more than a few hours, definitely not days unless there are issues with your nework and AD structure.
Part of that setup time includes setting a schedule for future full and incremental imports so that it can pick up changes from AD.
Where imports can get more complicated is when you need to map additional profile properties to AD or another source. The mechanisms are not complicated, but it takes some additional time to setup.
The personalization settings have two main components; My Sites and the Profiles discussed above. For My Sites, I like to think of that as "home base" for employees. It provides a great place for them to store some of their private files and data like Tasks, and then it can be used to pull together files and tasks that they are involved with throughout the SharePoint farm.
SharePoint Developer | Administrator | Evangelist -- Twitter -- Blog - http://nextconnect.blogspot.com- Marcado como respuestaSP Brian lunes, 06 de julio de 2009 15:50
- MySite is only available in MOSS (both Standard and Enterprise) but not in WSS.
- Marcado como respuestaSP Brian lunes, 06 de julio de 2009 15:50
- There are a few ways it can integrate with Outlook so I would recommend that you expiriment and see what matches your needs the best.
First you can sync Tasks from SharePoint into Outlook. For outlook tasks not in SharePoint, you can display them using the web parts that work with Outlook Web Access (OWA).
It is one of those things where you want to figure out what makes the most sense. Personally, I think that if you get to the point where things are the way they should be all tasks should be in SharePoint sites, including personal tasks stored on the MySite and then aggregated together into the one spot. If there is a need, pull those tasks down into Outlook for Offline access. The usage pattern that I strive for though is to do as much of that sort of work in the MySite as possible, and only using Outlook for emails.
There are about 12-15 standard fields that are mapped from AD by default. Things like the name, email address, title, deptartment, supervisor, etc. There are many more fields created in SharePoint that are not mapped, and you also have the ability to create your own custom fields to meet your business requirements. If you wanted to map any of these other fields, then that would take a little more time depending on the source of the data. The standard fields are enough for the majority of the organizations I've talked with.
SharePoint Developer | Administrator | Evangelist -- Twitter -- Blog - http://nextconnect.blogspot.com- Marcado como respuestaSP Brian lunes, 06 de julio de 2009 16:35
That is why I said expirment and see what would work in your org. If everyone is set and happy using tasks in Outlook then there is no reason to force a change yet.
A year from now they may start playing with the Task list on their personal site and decide they like it better and you can revisit the decision then. It doesn't change the install or anything to use or not use it.
The only place that tasks really might be manditory is if you are assigning workflow actions which rely on a Task list. They can also receive emails though so it could be transparent to them.
SharePoint Developer | Administrator | Evangelist -- Twitter -- Blog - http://nextconnect.blogspot.com- Marcado como respuestaSP Brian martes, 07 de julio de 2009 12:15
- when you define a custom field, you can associate a policy and specify who can visualize the field (colleague, everyone,...) in the public view; indeed, there is a public view.
Serge Luca; blog: http://www.redwood.be- Marcado como respuestaSP Brian miércoles, 08 de julio de 2009 21:09
- The MySite is separate from the Profiles. The profiles can be viewed by the owner, or anyone else in the org with access. The policy dectates the security scope (who can see it). Based on the viewer's relationship to the profile they are viewing it will show the appropriate properties. The custom properties behave the same was that the standard pre-mapped fields behave.So in a sense there are varying levels of "prviate/public" to the profiles.The actual mysite, where things like documents, task lists, and or other content are displayed is completely different. This is handled with regular site security. By default the owner has full control and org members have limited access to the site and some objects like the "Shared Documents" versus "Private Documents."
SharePoint Developer | Administrator | Evangelist -- Twitter -- Blog - http://nextconnect.blogspot.com- Marcado como respuestaSP Brian jueves, 09 de julio de 2009 2:42
- SP Brian, you will then find that you can leverage this profile information in the SSP within your InfoPath forms in order to do some tons of incredibly useful things. You've already seen my blog, but if you haven't read this one, then you should get ready for it, because you'll love it for use with your InfoPath forms once you have MOSS:
InfoPath - Get user information without writing code (extended)
The SSP exposes web services that are easy to use in InfoPath as data connections, and all that profile data is at your fingertips as if you were reaching into AD.
SharePoint Architect || My Blog- Marcado como respuestaSP Brian jueves, 09 de julio de 2009 13:30
Todas las respuestas
- The my site contact information is fetched from the (MOSS) user profile and can be centrally maintained by someone or by the user itself. It is customizable (you can add your own variable, like mentor, language,...) and specify the visibility level of the information (who can see what : you manager, your colleagues,...).
More details here ("MOSS User Profile Info - How the information flows").
Serge Luca; blog: http://www.redwood.be- Marcado como respuestaSP Brian lunes, 06 de julio de 2009 15:50
- MySite questions go to Social Computing.
Moving this
WSS FAQ sites: http://wssv2faq.mindsharp.com and http://wssv3faq.mindsharp.com
Total list of WSS 3.0 / MOSS 2007 Books (including foreign language) http://wssv3faq.mindsharp.com/Lists/v3%20WSS%20FAQ/V%20Books.aspx - So, it appears that the AD can feed te SSP database which, in turn, feed information into the MySites. Is that correct?
How easy is this to setup (difficultly level), and how long do you think this would take? Our AD stores information on over 70,000 people. I am not sure if that makes a difference or not. Are there any costs related to this process other than the hours that employees would dedicate to getting this setup? Are MySites only available on the MOSS platform or can this be accomplished on WSS? Right now, we are running off of WSS, but this year we plan to switch everything to MOSS. - The SSP and the Proile is a pretty rich feature set. Setting up "standard" imports is very quick and easy with all of the standard fields pre-mapped for you. It shouldn't take more than 10-15 minutes to set it up. The import time varies based on a number of factors including the number of people, network structure, etc. I haven't done one with more than 20k accounts before, but I can't imagine it taking more than a few hours, definitely not days unless there are issues with your nework and AD structure.
Part of that setup time includes setting a schedule for future full and incremental imports so that it can pick up changes from AD.
Where imports can get more complicated is when you need to map additional profile properties to AD or another source. The mechanisms are not complicated, but it takes some additional time to setup.
The personalization settings have two main components; My Sites and the Profiles discussed above. For My Sites, I like to think of that as "home base" for employees. It provides a great place for them to store some of their private files and data like Tasks, and then it can be used to pull together files and tasks that they are involved with throughout the SharePoint farm.
SharePoint Developer | Administrator | Evangelist -- Twitter -- Blog - http://nextconnect.blogspot.com- Marcado como respuestaSP Brian lunes, 06 de julio de 2009 15:50
- MySite is only available in MOSS (both Standard and Enterprise) but not in WSS.
- Marcado como respuestaSP Brian lunes, 06 de julio de 2009 15:50
- Mike,
How do the MySites integrate with Outlook? For example, if I update my task list in Outlook, does that automatically update my MySite? And so, would get my tasks from Outlook and my tasks through our SharePoint farm and have one unified list of tasks within SharePoint? If this is so, would Outlook also show an updated lists of all tasks from my original task list that I created in Outlook as well as any tasks that I may have within the SharePoint farm?
Based off of the import piece about which you were informing me, were you saying that if we wanted to collect information that is in addition to what AD usually stores such as First Name, Last Name, etc., it would take a little more work to do this, but it is possible?
Thank you for the information. Please let me know if my questions are confusing.
-------------------------------------------------
Jenny,
Thank you for that answer. - There are a few ways it can integrate with Outlook so I would recommend that you expiriment and see what matches your needs the best.
First you can sync Tasks from SharePoint into Outlook. For outlook tasks not in SharePoint, you can display them using the web parts that work with Outlook Web Access (OWA).
It is one of those things where you want to figure out what makes the most sense. Personally, I think that if you get to the point where things are the way they should be all tasks should be in SharePoint sites, including personal tasks stored on the MySite and then aggregated together into the one spot. If there is a need, pull those tasks down into Outlook for Offline access. The usage pattern that I strive for though is to do as much of that sort of work in the MySite as possible, and only using Outlook for emails.
There are about 12-15 standard fields that are mapped from AD by default. Things like the name, email address, title, deptartment, supervisor, etc. There are many more fields created in SharePoint that are not mapped, and you also have the ability to create your own custom fields to meet your business requirements. If you wanted to map any of these other fields, then that would take a little more time depending on the source of the data. The standard fields are enough for the majority of the organizations I've talked with.
SharePoint Developer | Administrator | Evangelist -- Twitter -- Blog - http://nextconnect.blogspot.com- Marcado como respuestaSP Brian lunes, 06 de julio de 2009 16:35
Mike,
Thanks for your reply.
I agree that there needs to be a central location for storing tasks. I just think it is going to be too difficult to get everyone to move from storing tasks in Outlook to storing them in their MySite. You know how people get set in their ways, and there is no real way on controlling where they create their own custom tasks. At this point, they would have personally assigned tasks in Outlook, all the while having another task list in SharePoint. This could get confusing, and we wouldn't want people to check 2 different locations for their tasks. Once again, I agree with what you're saying, but actually putting this into action where the employees uses their MySite for their dedicated task list seems almost impossible to completely implement.That is why I said expirment and see what would work in your org. If everyone is set and happy using tasks in Outlook then there is no reason to force a change yet.
A year from now they may start playing with the Task list on their personal site and decide they like it better and you can revisit the decision then. It doesn't change the install or anything to use or not use it.
The only place that tasks really might be manditory is if you are assigning workflow actions which rely on a Task list. They can also receive emails though so it could be transparent to them.
SharePoint Developer | Administrator | Evangelist -- Twitter -- Blog - http://nextconnect.blogspot.com- Marcado como respuestaSP Brian martes, 07 de julio de 2009 12:15
- Thank you for your feedback. You have and others have been very informative. I appreciate it greatly.
- If someone is wanting to look up information on a person and the MySite contains custom fields that the AD does not, then can any employee view another's MySite and get all the information from the AD + custom fields?
I am basically wondering if there is a "public" view of each employee's MySite. - when you define a custom field, you can associate a policy and specify who can visualize the field (colleague, everyone,...) in the public view; indeed, there is a public view.
Serge Luca; blog: http://www.redwood.be- Marcado como respuestaSP Brian miércoles, 08 de julio de 2009 21:09
- The MySite is separate from the Profiles. The profiles can be viewed by the owner, or anyone else in the org with access. The policy dectates the security scope (who can see it). Based on the viewer's relationship to the profile they are viewing it will show the appropriate properties. The custom properties behave the same was that the standard pre-mapped fields behave.So in a sense there are varying levels of "prviate/public" to the profiles.The actual mysite, where things like documents, task lists, and or other content are displayed is completely different. This is handled with regular site security. By default the owner has full control and org members have limited access to the site and some objects like the "Shared Documents" versus "Private Documents."
SharePoint Developer | Administrator | Evangelist -- Twitter -- Blog - http://nextconnect.blogspot.com- Marcado como respuestaSP Brian jueves, 09 de julio de 2009 2:42
- Great reply. Very descriptive. This was exactly what I was looking for. Thanks Mike.
- SP Brian, you will then find that you can leverage this profile information in the SSP within your InfoPath forms in order to do some tons of incredibly useful things. You've already seen my blog, but if you haven't read this one, then you should get ready for it, because you'll love it for use with your InfoPath forms once you have MOSS:
InfoPath - Get user information without writing code (extended)
The SSP exposes web services that are easy to use in InfoPath as data connections, and all that profile data is at your fingertips as if you were reaching into AD.
SharePoint Architect || My Blog- Marcado como respuestaSP Brian jueves, 09 de julio de 2009 13:30
- Very nice Clayton. That might be something we can leverage in the future (well, it definitely will be as long as we continue to use InfoPath - I am one of the first to use it, so we'll see how things go - meaning: hopefully the company will decide to keep using InfoPath)
