Options:

1) Export content to Excel and then publish to list (or Export to list in Excel 2007). This is a pretty good approach to get the data carried over, 10 minute job. The downsides include that security on the list is lost as well as the different views. They would have to be recreated.

2) Export the list as a template and then reimport to MOSS. This is a very common approach for lists I've done elsewhere. Pros: Quick and supported mechanism, Cons: Too much data blows limits of template, you still lose the security ACLs. My list is under the content size limits. The issue here is getting the list to appear in the "create list" area. Have to work on this one! I'm a bit surprised that this doesn't work.

3) Copy and paste list directly in sharepoint designer. We all know it will fail – or at least it used to in FP2003. Yep, failed, it copies the content but doesn't invoke the correct SPS bits to create the list properly. Oh well. No surprises.

5) Use Tzunami. Oh dear. Had high hopes for this one. Doesn't seem to cope with host headers configuration of WSS2.0.

6) Use DocAve

http://www.avepoint.com/products/purchase

Options:

1) Export content to Excel and then publish to list (or Export to list in Excel 2007). This is a pretty good approach to get the data carried over, 10 minute job. The downsides include that security on the list is lost as well as the different views. They would have to be recreated.

2) Export the list as a template and then reimport to MOSS. This is a very common approach for lists I've done elsewhere. Pros: Quick and supported mechanism, Cons: Too much data blows limits of template, you still lose the security ACLs. My list is under the content size limits. The issue here is getting the list to appear in the "create list" area. Have to work on this one! I'm a bit surprised that this doesn't work.

3) Copy and paste list directly in sharepoint designer. We all know it will fail – or at least it used to in FP2003. Yep, failed, it copies the content but doesn't invoke the correct SPS bits to create the list properly. Oh well. No surprises.

5) Use Tzunami. Oh dear. Had high hopes for this one. Doesn't seem to cope with host headers configuration of WSS2.0.

6) Use DocAve

http://www.avepoint.com/products/purchase

This is my quick write up of making sure I could get my MOSS installation working with email enabled lists with Exchange running in the domain. I have a "Proof of Concept" domain where I can play to my heart's content and not worry about blowing up production services.

Infrastructure:

1) MOSS server – this is a web server configuration single box provides all services.

2) SQL 2005 – has all databases on including MOSS

3) Exchange 2003 server – single box provides all things Exchange including OWA (which is how I tell email in this POC domain).

Normal users receive email within the domain as: user@poc.local

I want the MOSS server to respond to listname@moss.poc.local or something similar.

First step is to get the exchange server up and running – hasn't been booted for a few months!

I then add the OU to the top of my domain as in the guide.

The next step is to configure DNS. Hmm…My normal DC doesn't seem to have the DNS admin tool – wierd. Ok install that, start it up and look at my DNS.

Add a new MX record (check!), log in to my MOSS server.

Arh. Need to add SMTP services.

Ok, start the IIS console (again!) and configure the SMTP service as per the guide. I've set mine SMTP server up for open access (it's not Internet connected).

Click on incoming email settting in the central console and configure as per guide and substituting my server names and domain names as appropriate.

I then go to a test list and set it's email address to be mytestlist@moss.poc.local

We're now ready to test! Wow. Ok, start an OWA session up and try emailing into the list. Well a good sign is that I don't get an undeliverable come back straight away. Has the email arrived?

No. Ah. Ok what do we do now? Have a quick look at event logs seems a good idea. Nothing in Exchange or MOSS logs.

Looking in Exchange Queue's I can see two email waiting to be delivered to my moss.poc.local domain.

My server name and my mail domain names do not match (unlike the example). I shall add an alias in the SMTP settings to match the domain that Exchange is trying to send to (in my case moss.poc.local).

Now my SMTP will respond to moss.poc.local as well as cvhpocmoss20072.poc.local. I give the service a quick restart just in case and force a connection from Exchange. Not good.

Lots of head scratching later. Ok, check over check list. I have created an SMTP connector. Hm..lets make it use smart connectors and give it IP address of MOSS server. Ooo. Mail now gets delivered!

And there is is in my Shared Doc library – yay!

A fabulous guide, you need to know a bit about SMTP, Exchange and DNS as well as MOSS to get it working but not that bad at all really.

This is my quick write up of making sure I could get my MOSS installation working with email enabled lists with Exchange running in the domain. I have a "Proof of Concept" domain where I can play to my heart's content and not worry about blowing up production services.

Infrastructure:

1) MOSS server – this is a web server configuration single box provides all services.

2) SQL 2005 – has all databases on including MOSS

3) Exchange 2003 server – single box provides all things Exchange including OWA (which is how I tell email in this POC domain).

Normal users receive email within the domain as: user@poc.local

I want the MOSS server to respond to listname@moss.poc.local or something similar.

First step is to get the exchange server up and running – hasn't been booted for a few months!

I then add the OU to the top of my domain as in the guide.

The next step is to configure DNS. Hmm…My normal DC doesn't seem to have the DNS admin tool – wierd. Ok install that, start it up and look at my DNS.

Add a new MX record (check!), log in to my MOSS server.

Arh. Need to add SMTP services.

Ok, start the IIS console (again!) and configure the SMTP service as per the guide. I've set mine SMTP server up for open access (it's not Internet connected).

Click on incoming email settting in the central console and configure as per guide and substituting my server names and domain names as appropriate.

I then go to a test list and set it's email address to be mytestlist@moss.poc.local

We're now ready to test! Wow. Ok, start an OWA session up and try emailing into the list. Well a good sign is that I don't get an undeliverable come back straight away. Has the email arrived?

No. Ah. Ok what do we do now? Have a quick look at event logs seems a good idea. Nothing in Exchange or MOSS logs.

Looking in Exchange Queue's I can see two email waiting to be delivered to my moss.poc.local domain.

My server name and my mail domain names do not match (unlike the example). I shall add an alias in the SMTP settings to match the domain that Exchange is trying to send to (in my case moss.poc.local).

Now my SMTP will respond to moss.poc.local as well as cvhpocmoss20072.poc.local. I give the service a quick restart just in case and force a connection from Exchange. Not good.

Lots of head scratching later. Ok, check over check list. I have created an SMTP connector. Hm..lets make it use smart connectors and give it IP address of MOSS server. Ooo. Mail now gets delivered!

And there is is in my Shared Doc library – yay!

A fabulous guide, you need to know a bit about SMTP, Exchange and DNS as well as MOSS to get it working but not that bad at all really.

http://blog.thekid.me.uk/archive/2007/07/25/debugging-tips-for-sharepoint-and-wss-exceptions.aspx

I must get my feeds updated with more good quality blogs!

http://blog.thekid.me.uk/archive/2007/07/25/debugging-tips-for-sharepoint-and-wss-exceptions.aspx

I must get my feeds updated with more good quality blogs!

But is it just me or does it have a number of flaws? It's almost there but not quite. A concrete example:

1) A team is working on a collaborative document and then wishes to publish to a common repository for the rest of the business. This document will undergo periodic revision but have an internal review before it makes it live.

2) The sharepoint admin sets up the team collaborative site and the common repository site.

3) The authoriser of the document publishes the document to the common repository once authorised.

Problem number 1: When the user selects the option in "Prompt the author to send out updates when the document is checked in? " it doesn't work.

If we do explicit check in/check out nothing happens or if we do saves and hence implicit check-in.

Problem number 2: If we then edit the copy directly the linkage starts to go very funny. I've then gone back to the source and recopied (by using exiting copies menu item) and now I have two links to the same location! Bravo.

Problem 3: We delete the source document, the "linked" documents still have the "go to source" link in the menu. Clicking this of course generates an error for the user. These symbolic link files really should be done properly. Deleteing the source should either delete all the copies (if we are going for the master / copies metaphor this is the winner) or they should break the link. Possibly with a warning to the user before they delete.

Problem 4: A link to a link. This occurs if you "send to" a dc lib and then "send to" a second doc lib. All well and good and valid. The issue comes if you push the original, it doesn't know about the further links. The act of overwriting the "middle" version removes the metadata that says "oh by the way you have some copies out there at these URLs". The link in the 3rd copy still points back at the middle of course.

Good but not perfect. Its like sym links have never been invented and somebody is coming at this problem from fresh.

But is it just me or does it have a number of flaws? It's almost there but not quite. A concrete example:

1) A team is working on a collaborative document and then wishes to publish to a common repository for the rest of the business. This document will undergo periodic revision but have an internal review before it makes it live.

2) The sharepoint admin sets up the team collaborative site and the common repository site.

3) The authoriser of the document publishes the document to the common repository once authorised.

Problem number 1: When the user selects the option in "Prompt the author to send out updates when the document is checked in? " it doesn't work.

If we do explicit check in/check out nothing happens or if we do saves and hence implicit check-in.

Problem number 2: If we then edit the copy directly the linkage starts to go very funny. I've then gone back to the source and recopied (by using exiting copies menu item) and now I have two links to the same location! Bravo.

Problem 3: We delete the source document, the "linked" documents still have the "go to source" link in the menu. Clicking this of course generates an error for the user. These symbolic link files really should be done properly. Deleteing the source should either delete all the copies (if we are going for the master / copies metaphor this is the winner) or they should break the link. Possibly with a warning to the user before they delete.

Problem 4: A link to a link. This occurs if you "send to" a dc lib and then "send to" a second doc lib. All well and good and valid. The issue comes if you push the original, it doesn't know about the further links. The act of overwriting the "middle" version removes the metadata that says "oh by the way you have some copies out there at these URLs". The link in the 3rd copy still points back at the middle of course.

Good but not perfect. Its like sym links have never been invented and somebody is coming at this problem from fresh.

I thought I would check (for my own sanity) what the locale settings are on my servers and just try to bottom out a misconfiguration issue ahead of assuming it is a bug.

MOSS should have inherited the locale setting correctly shouldn't it? Time to go and check what is going wrong.

1. Check the Time zone setting on at the web application level (in Manage Web Application Settings). Yes, set correctly.
2. Check the locale of the computer. This is set correctly in Regional settings control panel applet. Yes, also set correctly.
3. The Microsoft help (http://office.microsoft.com/en-us/sharepointserver/HA101774731033.aspx) refers to the default language of the site collection. Right. How exactly do I set that then? Well you can't from the UI. What you can set is the regional setting on a per site basis and you change the top level site and then all new sites will inherit this setting. Old sites will retain their locale settings. You can do this for portal sites and team site site collections.
4. Ok, browse via the Site Settings or http://siteurl/_layouts/regionalsetng.aspx URL. Don't forget to check the "subsites inherit these regional settings" if you see it (portal).
5. Ok, the Site Collection root site now has the correct locale and new sites do indeed inherit correctly. That stinks. Why was "English (US)" the default locale in MOSS when it wasn't anywhere else?
6. Are all Site Collections similarly flawed? What locale is the My Site? Broken. Not very surprising but what a pain. My sites are really flawed (each my site is a site collection hence all users have to reset locale manually!)
7. Is this just as bad if you are French, Swedish, etc or just a pain if you are a "non-US English" English speaker?

Apparently it is. I just found the following thread. http://suguk.org/forums/2/3774/ShowThread.aspx

Bah.

I thought I would check (for my own sanity) what the locale settings are on my servers and just try to bottom out a misconfiguration issue ahead of assuming it is a bug.

MOSS should have inherited the locale setting correctly shouldn't it? Time to go and check what is going wrong.

1. Check the Time zone setting on at the web application level (in Manage Web Application Settings). Yes, set correctly.
2. Check the locale of the computer. This is set correctly in Regional settings control panel applet. Yes, also set correctly.
3. The Microsoft help (http://office.microsoft.com/en-us/sharepointserver/HA101774731033.aspx) refers to the default language of the site collection. Right. How exactly do I set that then? Well you can't from the UI. What you can set is the regional setting on a per site basis and you change the top level site and then all new sites will inherit this setting. Old sites will retain their locale settings. You can do this for portal sites and team site site collections.
4. Ok, browse via the Site Settings or http://siteurl/_layouts/regionalsetng.aspx URL. Don't forget to check the "subsites inherit these regional settings" if you see it (portal).
5. Ok, the Site Collection root site now has the correct locale and new sites do indeed inherit correctly. That stinks. Why was "English (US)" the default locale in MOSS when it wasn't anywhere else?
6. Are all Site Collections similarly flawed? What locale is the My Site? Broken. Not very surprising but what a pain. My sites are really flawed (each my site is a site collection hence all users have to reset locale manually!)
7. Is this just as bad if you are French, Swedish, etc or just a pain if you are a "non-US English" English speaker?

Apparently it is. I just found the following thread. http://suguk.org/forums/2/3774/ShowThread.aspx

Bah.