By default, a MOSS 2007 intranet / portal will display "Home" in the browser title bar.
To change this to reflect your intranet or portal name, locate the default.aspx page (top-level View All Site Content / Pages library) and choose Edit Properties (you will need to check out the file):
You will see that "Home" is entered in the Title field. Simply change this to the desired name.
When you save your change and check in the page, the intranet or portal name will be displayed when you click on the Home tab. (All other tabs will display their own information and must be changed individually).
FYI - changing the page title can also be done via the Page Settings function off the Publishing toolbar (when the page is in Edit mode or checked out):
They are a nationwide organization and wanted their intranet set up with alternative access mapping such that folks inside the headquarters use one URL to access their site, and folks in remote locations use a verified address (https://) to access the same site.
They had set up each of the top-level sites in their intranet with a content editor web part to display a welcome message which often included links to relevant pages within the intranet. The sites are maintained by content managers in various geographic locations. They noticed that once the alternative access mapping was set up, the links within the content editor web parts were broken for external users. We advised them to change all the links to the relative URL, which they did, but still reported the issue.
Troubleshooting revealed that whenever any content manager changed the content editor web part, whether in Rich Text or HTML view, the links in the web part would convert to the absolute link of the location of that content manager (i.e., when the content editor web part was edited within the network, the links began with http://, and when the content editor web part was edited outside the network, the links began with https://). The result is that, as the web parts are edited, links appear to be broken for part of the user base.
The problem, for my client, is that their sites were created as system sites (using the "Team" or "Blank" site template), and the Rich HTML field control (the Page Content control) can only be used on Publishing sites, i.e., sites based on a Publishing layout content type.
Activating the Publishing feature on a system site adds some Publishing Site functionality but does not change the content type of the site's pages. The Rich HTML field control is not available to the default.aspx page for any site that began life as a system site (using the "Team" or "Blank" site template, etc.). The following screen shot from SharePoint designer illustrates what you see when you try to access these controls from such a site.
Thinking to save my client from having to re-create all their team sites as publishing sites, I tested the strategy of creating a new default.aspx page based on the Publishing layout. This kind of page, in a Publishing site, is stored in the Pages library. I was able to create a page that looked exactly like the original default.aspx page, and which allowed the Page Content / Rich HTML control. However -
You can't set a default.aspx page that is stored in a Pages library to be the home page of a site that was not created as a Publishing site (using the "Set as home page" command in SharePoint Designer). It doesn't seem possible to swap the layout of a page once it has been created. And there does not seem to be a way to point the site's existing tab to the Pages library rather than to the top level to access its home page. The property that points to the location of a site's home page is deeply buried within the code.
At this point I'm thinking the options available to my client are:
remove the links from the Content Editor web parts; use a nearby Links list on each page instead (clunky, as the links are currently integrated with the welcome text)
convert all the sites to publishing sites, create new default.aspx pages for all sites, and then hide the existing tabs and create new tabs that point to the new default.aspx pages (cheesy, and not a little labor-intensive)
recreate all sites as Publishing sites (very labor-intensive)
The upshot here is, beware the Content Editor web part if your SharePoint site will be accessed via multiple URLs. Consider Publishing Sites for your top-level sites. I hope to post more on the differences between Publishing Sites and System Sites later this month.
In the meantime, I welcome any suggestions for my client's situation.
I used the "Import Spreadsheet" command in SharePointfor the first time this week, and got the following error after going through the steps of naming the list, browsing to the spreadsheet, and selecting a range:
Method 'Post' of object 'IOWSPostData' failed
I then tried exporting the list from the Excel side, and was also not successful. I'm running Office 2007, MOSS 2007, and Vista. What ended up fixing this for me was to repair MS Office via the Control Panel / Programs and Features function. At first I tried modifying the the Excel Add-In EXPTOOWS.XLA as described in this forum:
It worked (I used lver=3 and commented out the previous line), but I wasn't able to save the file, which meant I'd have to modify that piece of code every time I wanted to upload a spreadsheet. Happily, a repair of MS Office did the trick.