Dave Wollerman's SharePoint Blog - All Comments

re: Moving to a new database server (or instance)

Brendan — Thu, 04 Dec 2008 00:04:14 GMT

Do the search databases really need to be transferred during the backup? After creating the new farm and starting the search services, new databases are created. Omit the old ones and perform a crawl when finished?

Posted on SharePoint Blogs

re: SharePoint and Managed Paths

Bill — Wed, 03 Dec 2008 18:35:50 GMT

thanks for your explanation -

Posted on SharePoint Blogs

re: Huge MOSS Workflow Issue... What is Microsoft Thinking!!!! - Part 2

r0bertsid — Wed, 19 Nov 2008 16:34:27 GMT

Juan...how does one acquire the full version?

Posted on SharePoint Blogs

re: Caution: User Profile Image

Paul — Thu, 13 Nov 2008 00:52:25 GMT

Why in God's name wouldn't it just resize and crop the images (perhaps through a UI) to achieve this like any other CMS worth its salt.

The functionality to manipulate images at upload time is a major limitation in MOSS. Most users simply don't have the know-how or the software to achieve this properly.

Posted on SharePoint Blogs

re: Moving to a new database server (or instance)

dwollerman — Mon, 03 Nov 2008 16:50:05 GMT

There are many ways moving to a new database server (same name or not) could lead to potential issues. Be sure to test out every detail of your scenario before proceeding in production. Make sure all version numbers match exactly before testing. Make sure all services which are running match exactly as well. Document the process exactly... every click, every configuration change.

Once you checked and tested... do it again. Do it now based on the documentation you written during the test. You cannot assume anything. If you assume anything, murphy's law is something will go wrong.

Posted on SharePoint Blogs

re: Moving to a new database server (or instance)

Mathew Newton — Fri, 31 Oct 2008 18:25:36 GMT

Hi,

We have WSS3.0 installed as a farm but running all services on the one server for now. The server we installed it on is running SQL2000 and we wish to upgrade to 2005. We are uninstalling the 2000 root instance and installing 2005 as the root instance. My question is because the server name is going to stay the same I thought we should be able to detach the WSS databases and reattach them in the new environment. The only thing at this point that is worrying us are any special users/roles/security settings but I thought as WSS uses windows authentication this may not be a big deal. Any feedback on this upgrade scenario would be appreciated.

Mat

Posted on SharePoint Blogs

re: Site Collection Logical Architecture

dwollerman — Thu, 30 Oct 2008 13:42:44 GMT

Kevin,

Let me break down your response and clarify each section...

Lifecycle management?

quick answer... yes. You want to position yourself and your environment to be effective in the long term as well as the short term. This means you have to develop a plan for archiving sites, being able to move sites between databases, content databases utlization, disk utilization, site locking, site disposition, etc.

Keep in mind how Microsoft has designed SharePoint. A content database can contain multiple site collections, although a site collection CANNOT span multiple databases. This is a main point of concern. Putting projects as sub-sites in a single site collection for a custom means you can only have one database. Multiple projects and the data associated with these projects can grow out of control if not propertly planned out. Also you cannot offer storage quotas for sub-sites... they all use the site collection storage quota. This means you either not set one (bad idea) or set one and have any one of the projects potentially utilize all the space for themselves.

Permissions?

What I mean by the same permissions is you don't want to get into the habit of managing unique permissions for sub-sites on different projects because it can get messy. If all the projects have the same permissions then great inherit permissions from the parent and manage the permissions in a single location. I tend to think this is not the case at the customer level. Odds are the permissiosn are unique at the project level.

With this said, you need to develop a plan for user management. This goes back to thinking for the long term as well as the short term. Short term you throw a sub-site out there, manage permissions for a few people who may just need access to that project... then before you know it they have you managing permissions for all projects across all customers. You need to delegate this out to project managers / admins. can you do this in sub-sites... sure, but now there are multiple different admins intertwined into the site collection structure, which means more uncontrolled growth. With a site collection you can more easily manage this piece as well.

Ah the infamous question, how do I manage all my projects for a customer in one place?

The easy answer... use a site directory. If you have moss you can utilize the site directory template for each customer which can provide a list of projects for them on their site. If you don't have MOSS and have WSS, you don't have the site directory template. Since the site directory template uses lists to store its data, you can create a custom list for them to track their sites with a list.

Another direction... use search. Again, if you have MOSS you can easily incorporate search to provide a list of site collections. The best part, search is security trimmed... meaning customers will only see site collections in which they have access to in the list. Since search results are rendered with XSL, you can easily customize the output the customers see.

Bottom line...

I highly recommend taking at least a couple days to make sure you cover most your bases and develop a long term strategy for sustaining the environment. Yes I know you won't be able to think of everything, but if you look to the past in how the company has done business and their trends and then follow within the lines of how Microsoft has architected SharePoint to work, then odds are for you in the event an unknown comes up. A well thoughout plan makes life easier for you in the long term. If there is no plan, every issue is a fire drill and a band-aid fix, which lead to more intense fire drills. You want to reduce the occurances and intesity of the fire drills and effectively resolve any unforseen issues... the best way to do this is to have a plan of attack and stay one step ahead of the curve.

Posted on SharePoint Blogs

re: Site Collection Logical Architecture

Kevin — Thu, 30 Oct 2008 12:01:45 GMT

Thank you for your reply.

We do multiple projects for multiple customers.

With lifecycle management I guess you mean cleaning up sites, backup/restore sites, etc.?

I think that projects need to be archived at some moment, otherwise the database would grow to large. Further more it would make the view messy, if discontinued projects would still show up.

Would that still be possible in this situation?

Also, different projects have different members. But 1 employee can work on different projects. In this situation, is it difficult to set up the appropriate rights? What do you mean with the user permissions are the same? The same for each project?

If I create a collection for each project, I will have to make a page in which I provide some form of structure per customer, right? With links to each collection for a project.

Could you please clarify the management issues that can cause troubles on the long run.

Thanks!

Kevin

Posted on SharePoint Blogs

re: Site Collection Logical Architecture

dwollerman — Wed, 29 Oct 2008 15:20:44 GMT

That is correct. You cannot specify 2 managed paths with the same name. Also you will want to stay away from having a wildcard managed path named the same as a sub-web under the root level site collection. This will cause sharepoint to get confused.

Take a look at using host header mode. You can esentially create "vanity" urls for each customer site collection. for example... http://customer.domain.com/ and creating sub webs for each project (http://customer.domain.com/projectA).

Keep in mind, having all projects for a customer as a sub-web is ok as long as 1) you don't need specific lifecycle management for each project 2) user permissions are the same (you want to stay away from too much unique permission management) 3) archive ability using backup methods or locking mechanisums provided by SharePoint. You might run into management issues in the long run by having projects as sub-webs under a customer.

Although sub-webs provide a better means for sharing content types, site columns, and rollup capabilities... I would make sure you weigh all the pros / cons on creating them in site collections vs. sub webs.

Posted on SharePoint Blogs

re: Site Collection Logical Architecture

Kevin — Wed, 29 Oct 2008 14:55:02 GMT

I've been busy designing an architecture for SharePoint, and came up with the following idea:

I would like to create a portal named customers. This would be a Site Collection. Then I wish to create a site collection for each customer, with subsites for each project we do for a customer.

Would this be a good approach?

And what about URLs. I would like URLs such as:

http://myserver/customers

http://myserver/customers/customerA

http://myserver/customers/customerA/projectA

It seems that this is not possible. If I create a manged path named 'customers', it is either a root path, or a path for which I need to specify an underlying path.

I can't host a site collection on the root of a path, and site collections on 'sub' paths?

Thanks!

Kevin

Posted on SharePoint Blogs

re: Huge MOSS Workflow Issue... What is Microsoft Thinking!!!! - Part 2

Juan Larios — Mon, 27 Oct 2008 15:42:40 GMT

SharePoint Workflow Audit solution available for download!

www.imaginets.com/.../sharepoint-workflow-audit-solution-trial-download.aspx

Juan

Posted on SharePoint Blogs

re: Huge MOSS Workflow Issue... What is Microsoft Thinking!!!!

Juan Larios — Mon, 27 Oct 2008 15:42:01 GMT

SharePoint Workflow Audit solution available for download!

www.imaginets.com/.../sharepoint-workflow-audit-solution-trial-download.aspx

Juan

Posted on SharePoint Blogs

re: Site Collection Logical Architecture

dwollerman — Sat, 25 Oct 2008 17:53:59 GMT

Rita,

Yes, feel free to use my image in your documentation.

Posted on SharePoint Blogs

re: Site Collection Logical Architecture

Rita Reynolds — Sat, 25 Oct 2008 17:41:40 GMT

I am working on developing a user guide for our IT staff as we set up our New SharePoint Farm. Would it be ok to use your diagram above in that user guide. It's by far, the best visual that I have come across for explaining the logical architecture

Posted on SharePoint Blogs

re: Site Collection Logical Architecture

dwollerman — Thu, 23 Oct 2008 16:02:34 GMT

Tasneem,

My recommendation is to not include the private collaboration information within the public site collection.

What I usually recommend is a public intranet site collection, which has public departmental information as sub sites. Then the private information is contained in their own site collections.

example...

http://intranet.company.com/

this is the root level site collection in the web application which contains the companies intranet which is public "formal" tightly governed information.

http://intranet.company.com/projects/???

site collections can use managed paths to define and organize team sites. Such as a projects managed path where all the project based site collections can be created, or a /departments/ managed path which allows department team sites to be created, or /sites/ which can be used for virtual team sites in general.

Keeping the private sites organized by specific topics which allow for better administration, maintenance, and lifecycle management of the site. along with providing the owner a more loosely goveren workspace for them to build something which suits their needs vs. someone elses.

Posted on SharePoint Blogs

re: Site Collection Logical Architecture

Tasneem Nomani — Thu, 23 Oct 2008 15:32:14 GMT

We are using site collections for our different departments. Accounting, HR, IT Marketing.

Now each of these departments will have public section which will be viwed by entire company and private psection which is a collaboration space within the department.

The logic that I am using to organize this structure is, have a site collection for each departmen which is public, then create a subsite to this site collection which will be private to taht deparment.

Pleas let me know if I am on the right parh, or should it be reversed.

Posted on SharePoint Blogs

re: Site Collection Logical Architecture

Samer Shennar — Wed, 22 Oct 2008 06:21:45 GMT

Thanks for your reply dwollerman. You mentioned some cool ideas that I were'nt aware of. However, your reply is also telling me that I have a big homework ahead, learning advanced search configuration :)

Posted on SharePoint Blogs

re: Site Collection Logical Architecture

dwollerman — Tue, 21 Oct 2008 12:19:29 GMT

Samer,

Microsofts answer to aggregation is Content Query Web Part (for intra site collection content) and their only real good solution for inter-site collection aggregation is search. If you are running MOSS, you can configure search to return the information you are looking for.

With the use of content types and site columns in conjunction search managed properties will allow you to configure the search core results web part to pull only specific relevant information. The bonus is since it is useing search to return this information, it is automatically security trimmed as well.

Since search results are returned using XML, all you need is to configure the XSL to render the content any which way you need. Making it into a calendar might prove complicated with straight XSL, but I am sure it can be rendered in such a way to make it a quick win for your situation.

Other options of course rely on developing a solution using .net, especially if you choose to render into a calendar.

Posted on SharePoint Blogs

re: Site Collection Logical Architecture

Samer Shennar — Tue, 21 Oct 2008 10:12:47 GMT

I got aware of this early in my deployment. I'm creating site collections on the departmental level. Section level is planned to be subsites. How ever my -BIG- question is: How to aggregate several site collections' content when needed? I hope this doesn't require asking the development team to do .net digging for every simple requirement. I appreciate any help.

An example of what I need would be or instance:

Leaves Callendar:

That is, if every department includes a calendar to record their staff leaves, how could an upper level manager look at all of the organization's staff leaves in a single calendar by collecting information from each department's site collection?

Posted on SharePoint Blogs

SpittingCAML » Another reason to ditch vanilla MOSS Workflow and create your own!

Sun, 19 Oct 2008 10:16:56 GMT

Pingback from SpittingCAML » Another reason to ditch vanilla MOSS Workflow and create your own!

Posted on SharePoint Blogs

re: Managed Paths: What are you using?

Mossguy — Sat, 18 Oct 2008 03:11:02 GMT

http://TLD:80

/mycompany (explicit)

/mylocation (wildcard)

/MyHr (Explicit)

/myorg (wildcard)

Posted on SharePoint Blogs

re: Moving to a new database server (or instance)

dwollerman — Thu, 16 Oct 2008 18:56:23 GMT

I don't want to say it will for sure as I have not tested that scenario, but I would think it should work since sharepoint is looking for the server name. The only issue i see is sharepoint will be down during the time you are getting the new server provisioned.

Posted on SharePoint Blogs

re: Moving to a new database server (or instance)

Joe Alonge — Thu, 16 Oct 2008 18:32:14 GMT

I want to setup a 64 bit sql server and give it the same name as the old server and move all the databases over. Would that work?

Posted on SharePoint Blogs

re: Caution: User Profile Image

nando — Thu, 16 Oct 2008 18:13:42 GMT

it seems to be a bug doesn't it. I would upload pictures at 140x140 and that should take care of the issue.

Posted on SharePoint Blogs

Algunas ligas de interés

Aprende a Dominar SharePoint con tips de los expertos — Wed, 15 Oct 2008 05:03:29 GMT

Movimiento de bases de datos de SharePoint (distintas opciones) SharePoint Site Moves, Database Moves

Posted on SharePoint Blogs