Friday, April 27, 2007
Shared Service Provider Access Denied
As I have had plenty of time playing with MOSS installs/upgrades over the last week (in between jobs), I discovered an interesting behaviour with Shared Service providers. I tried to simulate a proper production install, so I installed MOSS and configured the farm with a test administrator account (e.g. testadmin). During the upgrade process (database migration of the _PROF, _SERV and _SITE db) I logged on as a different administrator (not a domain admin, but a local admin on the box). Well the upgrade went through without a problem and I was able to restore the SSP. I then added myself to have full control over the dev intranet site and the SSP site (using Policy for Web Application). I then navigated to the SSP site and configured the search. Then I went to update the profile information and it was there that I got the old Access Denied, you must sign in as someone else. After scratching my head for a while, I discovered the 'Personalization services permissions' hyperlink in the SSP site. So I logged back in as testadmin (who at this time was the only user who could actually get to the profile settings page), invoked this function and added a new group to the list, giving them 'Create personal site', 'Use personal features', 'Manage user profiles', 'Manage audiences', 'Manage permissions' and 'Manage usage analytics' rights, and low and behold I was able to edit profile settings with my normal local administrator account.
Tuesday, April 17, 2007
My last week at SDM
Well it was a tough decision, but I have decided to leave SDM and start my own business (MS-Advantage Pty Ltd). I start a 9 month contract with DiData on Monday the 30th of April.
It will be sad to go, but I am looking forward to the challenges ahead. SDM is a great company to work for with some very talented people.
It will be sad to go, but I am looking forward to the challenges ahead. SDM is a great company to work for with some very talented people.
Update on SharePoint ASPMenu control
It ended up being caused by a custom developed breadbrumb control that was requiring extra credentials in order to query the parent site title. We ended up having to remove the control.
Wednesday, April 04, 2007
SharePoint ASPMenu control is prompting for user credentials if it finds draft documents on the public site
I am working on an MOSS internet project at the moment, and today I came across a strange behaviour in development where users get prompted for their credentials.
Background
Basically I setup a staging environment and did a full deployment through an ISA firewall to a destination server. I then setup anon security on the destination site. After making some changes to pages in development, I then ran a deployment to copy across changed files since the last deployment. One of the things I noticed (and I wasn't aware of this) was that during a content deployment, it is not only the published files that get deployed, but also Draft pages. It doesn't seem to matter whether it is a full deployment or only the deployment of changes - draft content still gets sent across (which is bad).
Now I have a couple of Master pages, each of which contains 3 content placeholder ids (PlaceHolderLeftNavBar, PlaceHolderMain, PlaceHolderAdSpace). The page layout used only overwrites the PlaceHolderMain and PlaceHolderAdSpace regions (i.e. no reference to PlaceHolderLeftNavBar at all). In this case, my main master page outputs the ASPMenu control in the PlaceHolderLeftNavBar space. My other master page contains the 3 content placeholders, but does not put anything into the PlaceHolderLeftNavBar area (and as the page layout doesn't reference this id also, nothing gets rendered in the left nav area).
The Experienced Problem
On the destination server, when the master page with the ASPMenu left nav gets used, if there is any draft pages that it finds, it prompts for credentials, instead of just hiding them. If I switch master pages so that the ASPMenu is no longer rendered on the page, the user does not get prompted.
If anyone knows why this is and knows how to fix it, please post a comment.
Background
Basically I setup a staging environment and did a full deployment through an ISA firewall to a destination server. I then setup anon security on the destination site. After making some changes to pages in development, I then ran a deployment to copy across changed files since the last deployment. One of the things I noticed (and I wasn't aware of this) was that during a content deployment, it is not only the published files that get deployed, but also Draft pages. It doesn't seem to matter whether it is a full deployment or only the deployment of changes - draft content still gets sent across (which is bad).
Now I have a couple of Master pages, each of which contains 3 content placeholder ids (PlaceHolderLeftNavBar, PlaceHolderMain, PlaceHolderAdSpace). The page layout used only overwrites the PlaceHolderMain and PlaceHolderAdSpace regions (i.e. no reference to PlaceHolderLeftNavBar at all). In this case, my main master page outputs the ASPMenu control in the PlaceHolderLeftNavBar space. My other master page contains the 3 content placeholders, but does not put anything into the PlaceHolderLeftNavBar area (and as the page layout doesn't reference this id also, nothing gets rendered in the left nav area).
The Experienced Problem
On the destination server, when the master page with the ASPMenu left nav gets used, if there is any draft pages that it finds, it prompts for credentials, instead of just hiding them. If I switch master pages so that the ASPMenu is no longer rendered on the page, the user does not get prompted.
If anyone knows why this is and knows how to fix it, please post a comment.
Monday, April 02, 2007
Microsoft ForeFront may cause WCM deployment to fail
Today at a client site I noticed that content deployment just stopped working from my staging environment to the live site. Basically the job said that it failed, but gave no errors or warnings at the staging environment end. So I started to investigate what was going on within the destination server. The event log had the following error:
Failed import operation for Content Deployment job 'Remote import job for job with sourceID = f483830c-116d-4fd1-9d68-5dc6df9bd2cf'. Exception was: 'Microsoft.SharePoint.SPException: Exception from HRESULT: 0x81070000 ---> System.Runtime.InteropServices.COMException (0x81070000): Exception from HRESULT: 0x81070000
at Microsoft.SharePoint.Library.SPRequestInternalClass.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish)
at Microsoft.SharePoint.Library.SPRequest.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish)
--- End of inner exception stack trace ---
at Microsoft.SharePoint.Library.SPRequest.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish)
at Microsoft.SharePoint.SPListItem.AddOrUpdateItem(Boolean bAdd, Boolean bSystem, Boolean bPreserveItemVersion, Boolean bNoVersion, Boolean bMigration, Boolean bPublish, Boolean bCheckOut, Boolean bCheckin, Guid newGuidOnAdd, Int32& ulID, Object& objAttachmentNames, Object& objAttachmentContents, Boolean suppressAfterEvents)
at Microsoft.SharePoint.SPListItem.UpdateInternal(Boolean bSystem, Boolean bPreserveItemVersion, Guid newGuidOnAdd, Boolean bMigration, Boolean bPublish, Boolean bNoVersion, Boolean bCheckOut, Boolean bCheckin, Boolean suppressAfterEvents)
at Microsoft.SharePoint.SPListItem.Update()
at Microsoft.SharePoint.SPAttachmentCollection.AddNow(String leafName, Byte[] data)
at Microsoft.SharePoint.Publishing.Administration.JobReportBase.Update()
at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.importexport_Error(Object sender, SPDeploymentErrorEventArgs errorEventArg)
at Microsoft.SharePoint.Deployment.SPDeployment.OnError(SPDeploymentErrorEventArgs e)
at Microsoft.SharePoint.Deployment.DeploymentLogger.Log(DeploymentLogSeverity severity, SPDeploymentObject deplObject, String message, Boolean throwException)
at Microsoft.SharePoint.Deployment.DeploymentLogger.Log(DeploymentLogSeverity severity, SPDeploymentObject deplObject, Exception exception, Boolean throwNewException)
at Microsoft.SharePoint.Deployment.DeploymentLogger.Log(DeploymentLogSeverity severity, Exception exception, Boolean throwNewException)
at Microsoft.SharePoint.Deployment.SPImport.Run()
at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.DoImport()'
This would be a tricky one to fix...
So I dug deeper into the event log and noticed that a couple of days before, when there were no errors, this service called GetEngineFiles (i.e. ForeFront) had been started. The service was having numerous problems accessing the internet to updated its various scanning engines (because it was a dev machine, and external web access was blocked by the proxy). So I walked over to the infrastructure guys and politely asked 'What the F@#% have you been doing with my server?'. To this they responded 'oh, we installed Microsoft Forefront on it a couple of days ago and configured SharePoint to integrate with it'. So I again politely asked for them to uninstall it and reboot the machine. After this, miracles of miracles, the WCM deployment started working again.
There endith the lesson - Without communication, we would all be lost!
Failed import operation for Content Deployment job 'Remote import job for job with sourceID = f483830c-116d-4fd1-9d68-5dc6df9bd2cf'. Exception was: 'Microsoft.SharePoint.SPException: Exception from HRESULT: 0x81070000 ---> System.Runtime.InteropServices.COMException (0x81070000): Exception from HRESULT: 0x81070000
at Microsoft.SharePoint.Library.SPRequestInternalClass.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish)
at Microsoft.SharePoint.Library.SPRequest.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish)
--- End of inner exception stack trace ---
at Microsoft.SharePoint.Library.SPRequest.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish)
at Microsoft.SharePoint.SPListItem.AddOrUpdateItem(Boolean bAdd, Boolean bSystem, Boolean bPreserveItemVersion, Boolean bNoVersion, Boolean bMigration, Boolean bPublish, Boolean bCheckOut, Boolean bCheckin, Guid newGuidOnAdd, Int32& ulID, Object& objAttachmentNames, Object& objAttachmentContents, Boolean suppressAfterEvents)
at Microsoft.SharePoint.SPListItem.UpdateInternal(Boolean bSystem, Boolean bPreserveItemVersion, Guid newGuidOnAdd, Boolean bMigration, Boolean bPublish, Boolean bNoVersion, Boolean bCheckOut, Boolean bCheckin, Boolean suppressAfterEvents)
at Microsoft.SharePoint.SPListItem.Update()
at Microsoft.SharePoint.SPAttachmentCollection.AddNow(String leafName, Byte[] data)
at Microsoft.SharePoint.Publishing.Administration.JobReportBase.Update()
at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.importexport_Error(Object sender, SPDeploymentErrorEventArgs errorEventArg)
at Microsoft.SharePoint.Deployment.SPDeployment.OnError(SPDeploymentErrorEventArgs e)
at Microsoft.SharePoint.Deployment.DeploymentLogger.Log(DeploymentLogSeverity severity, SPDeploymentObject deplObject, String message, Boolean throwException)
at Microsoft.SharePoint.Deployment.DeploymentLogger.Log(DeploymentLogSeverity severity, SPDeploymentObject deplObject, Exception exception, Boolean throwNewException)
at Microsoft.SharePoint.Deployment.DeploymentLogger.Log(DeploymentLogSeverity severity, Exception exception, Boolean throwNewException)
at Microsoft.SharePoint.Deployment.SPImport.Run()
at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.DoImport()'
This would be a tricky one to fix...
So I dug deeper into the event log and noticed that a couple of days before, when there were no errors, this service called GetEngineFiles (i.e. ForeFront) had been started. The service was having numerous problems accessing the internet to updated its various scanning engines (because it was a dev machine, and external web access was blocked by the proxy). So I walked over to the infrastructure guys and politely asked 'What the F@#% have you been doing with my server?'. To this they responded 'oh, we installed Microsoft Forefront on it a couple of days ago and configured SharePoint to integrate with it'. So I again politely asked for them to uninstall it and reboot the machine. After this, miracles of miracles, the WCM deployment started working again.
There endith the lesson - Without communication, we would all be lost!
Monday, March 19, 2007
Simple way to apply colour schemes across your site
You could use themes, but an easier way is to create separate stylesheets that override base styles that you have created (with different colour schemes). Then within each top level site that you want to apply the colour scheme to, navigate to Site Settings | Master page, and in the alternate CSS URL section, select the 'Specify a CSS file to be used by this publishing site and all sites that inherit from it' radio button and then specify the path to your alternate CSS file. Pretty straight forward really. :-)
Web Design Tools that I can no longer live without
One of the biggest pains when building a new web site on MOSS is cross browser development and testing. Often, slight errors in stylesheets can have disasterous affects on different browsers. One of the tools that I have found help me in this regard is the FireBug add-in within Firefox. This tool lets you inspect a particular element on the page. It then tells you where it is picking up the associated styles for the selected element. It references each stylesheet name that has been included, the line number, and which CSS attributes are being ignored. It really helps you to quickly identify bizaar behaviours within a page.
Wednesday, March 07, 2007
MOSS 2007 - Web Part Pages don't display the left navigation
I discovered this on my current project. Bizaar - web part pages never render the left navigation. This looks crap, because you flick from publishing pages that display the left nav to web part pages that don't.
I hunted around to find a fix and here it is...
The Master page contains the following two Content Placeholders, which are instructed by the web part pages not to load.
<asp:contentplaceholder id="PlaceHolderLeftNavBar" runat="server"> "CODE" </asp:ContentPlaceHolder>
<asp:contentplaceholder id="PlaceHolderNavSpacer" runat="server">"CODE"</asp:ContentPlaceholder>
Basically within these two content placeholders you move each 'CODE' block outside each ContentPlaceHolder tag.
NOTE:DO NOT delete the Content Placeholders, as they are still needed to render (load) the page. The page will error if they are deleted.
I hunted around to find a fix and here it is...
The Master page contains the following two Content Placeholders, which are instructed by the web part pages not to load.
<asp:contentplaceholder id="PlaceHolderLeftNavBar" runat="server"> "CODE" </asp:ContentPlaceHolder>
<asp:contentplaceholder id="PlaceHolderNavSpacer" runat="server">"CODE"</asp:ContentPlaceholder>
Basically within these two content placeholders you move each 'CODE' block outside each ContentPlaceHolder tag.
NOTE:DO NOT delete the Content Placeholders, as they are still needed to render (load) the page. The page will error if they are deleted.
Monday, March 05, 2007
An update on the Timed Out Deployment Job
Even though the job said that it had timed out, refreshing the page showed that it was successful, but with the error 'Content deployment job Full Deployment: Timed Out'. Clicking on this error shows the message 'The connection to the destination server was lost after the remote import job was started. The import job might still succeed. Content deployment will continue to attempt to reestablish a connection with the destination server.'
It would be good to have a repeatable, consistently successful deployment. Angus Logan from Microsoft suggested to change the timezone on the server to 1 hour prior, but that doesn't seem to have fixed the timeout problem.
It would be good to have a repeatable, consistently successful deployment. Angus Logan from Microsoft suggested to change the timezone on the server to 1 hour prior, but that doesn't seem to have fixed the timeout problem.
MOSS 2007 - No Results renders differently in People scope
Within MOSS, there are two different web part instances to display the search results between the 'All Sites' tab and the 'People' tab. When you are on the all items tab, it is called the 'Search Core Results' web part, whereas in the People tab it is called the People Search Core Results web part. For some strange reason, the XSL for rendering the No Search results is different in these two pages. The core search page uses a span tag with a class of 'srch-description', whereas in the people search, it uses a span tag with a class of 'ms-sbplain'. The ms-sbplain style often has a border around it because this style is used for the standard search entry input screen. Therefore the People search No Results message has borders around every peace of text that it renders. To fix the problem, switch to the People tag and edit the page. Edit the XSL associated with the People Search Core Results web part and replace the ms-sbplain style in the No Results section to srch-description.
Friday, March 02, 2007
First Real WCM Not so successful
Well it repeated the same error I had on my VPC environment - timed out.
"The connection to the destination server was lost after the remote import job was started. The import job might still succeed. Content deployment will continue to attempt to reestablish a connection with the destination server".
The export worked (i.e. it exported over 1800 pieces of content), but the import failed. Bugger!
"The connection to the destination server was lost after the remote import job was started. The import job might still succeed. Content deployment will continue to attempt to reestablish a connection with the destination server".
The export worked (i.e. it exported over 1800 pieces of content), but the import failed. Bugger!
My first real WCM Deployment
Today at a client site I was testing the deployment of a WCM site across to an external DMZ network. I had setup a blank site collection on the destination server, SSP etc, configured the Central Administration to accept deployment requests, then switched back to the development server to start the deployment. The next 2 hours would be painful...
When trying to setup the deployment path, it kept failing connecting to the destination Central Administration site. With the help of a local infrastructure guru we went into troubleshooting mode. There was no proxy configured and the web.config file of each site on the server was configured to not detect for one, yet on the firewall trace we could see that the server was communicating with the Proxy as an anonymous user. We could have allowed anonymous access on the proxy to fix the problem (which we did initially, but this is not the preferred approach), but their had to be a better way. We went off on tangents for a while, checking the registry against each of the system accounts to see if their settings were configured to use a proxy or to auto detect (which they weren't). We couldn't find where this 'Autodetect' IE setting was coming from (i.e. why was it going to the proxy).
Before I go into spelling out how we fixed it, here's a little lesson that I learnt from my infrastructure friend. Whenever a server looks for a server, it accesses a record called 'wpad' within the DNS. The wpad tells the client where to go find the server. The default setting was the proxy server (i.e. the ISA Server). The client then communicates with this server (i.e. the ISA Server) for a configuration file, which tells it which domains it can try to talk directly with and which ones have to go via the proxy. In our case, this config file was telling the client that every request must go through the proxy.
To fix the problem we modified ISA's automatic detections script. We added the external domains to the domain include list, which essentially tells it that a client request can try to talk to the remote server directly. We then modified the firewall rules (not ISA in this case) to allow communication from the specific source MOSS Server to the destination MOSS server on the nominated central administration port.
This fixed the communication problem immediately.
Next Steps - I configured the Quick Deploy settings to allow quick deployments to occur, then created another job for a full deployment. After trying to start the quick deploy and let it sit there for a while on the 'Preparing' status (I don't know whether this is a problem because of the OWSTimer bug working on UTC time and not GMT time), I cancelled the job. Funny thing was, shortly after this, the status changed to Running and then eventually to Failed.
I've now kicked off the full deployment, but at the moment it is still in the 'Preparing' state. I will keep you posted on whether or not this works (BTW, I have yet to get deployment to work on a VPC environment, where the source and destination sites are on the same server (and SQL is on the same Server too). The error I usually get is a timeout error. It would be good if Microsoft could provide some more technical notes about what is happening under the covers when a deployment occurs. There is some coding samples, but if the underlying plumbing is not working, whats the point.
When trying to setup the deployment path, it kept failing connecting to the destination Central Administration site. With the help of a local infrastructure guru we went into troubleshooting mode. There was no proxy configured and the web.config file of each site on the server was configured to not detect for one, yet on the firewall trace we could see that the server was communicating with the Proxy as an anonymous user. We could have allowed anonymous access on the proxy to fix the problem (which we did initially, but this is not the preferred approach), but their had to be a better way. We went off on tangents for a while, checking the registry against each of the system accounts to see if their settings were configured to use a proxy or to auto detect (which they weren't). We couldn't find where this 'Autodetect' IE setting was coming from (i.e. why was it going to the proxy).
Before I go into spelling out how we fixed it, here's a little lesson that I learnt from my infrastructure friend. Whenever a server looks for a server, it accesses a record called 'wpad' within the DNS. The wpad tells the client where to go find the server. The default setting was the proxy server (i.e. the ISA Server). The client then communicates with this server (i.e. the ISA Server) for a configuration file, which tells it which domains it can try to talk directly with and which ones have to go via the proxy. In our case, this config file was telling the client that every request must go through the proxy.
To fix the problem we modified ISA's automatic detections script. We added the external domains to the domain include list, which essentially tells it that a client request can try to talk to the remote server directly. We then modified the firewall rules (not ISA in this case) to allow communication from the specific source MOSS Server to the destination MOSS server on the nominated central administration port.
This fixed the communication problem immediately.
Next Steps - I configured the Quick Deploy settings to allow quick deployments to occur, then created another job for a full deployment. After trying to start the quick deploy and let it sit there for a while on the 'Preparing' status (I don't know whether this is a problem because of the OWSTimer bug working on UTC time and not GMT time), I cancelled the job. Funny thing was, shortly after this, the status changed to Running and then eventually to Failed.
I've now kicked off the full deployment, but at the moment it is still in the 'Preparing' state. I will keep you posted on whether or not this works (BTW, I have yet to get deployment to work on a VPC environment, where the source and destination sites are on the same server (and SQL is on the same Server too). The error I usually get is a timeout error. It would be good if Microsoft could provide some more technical notes about what is happening under the covers when a deployment occurs. There is some coding samples, but if the underlying plumbing is not working, whats the point.
Monday, February 26, 2007
MOSS 2007 - Import/Export Lessons Learnt
On my current project, we are required to use the stsadm export/import switch to move team sites to their new information architecture ('/sites/sitex' type syntax is not really required any more if you are happy for the sites to belong to the top level site collection). In addition to this, we wanted to migrate a site from another MOSS box to the new site. Once again we tried the export/import, but it didn't work.
Closer inspection revealed that although the export appeared to work (i.e. we got a success message), closer scrutiny of the export log shows that not all objects were correctly exported (in our case, some of the list definitions). This was due to the account that we were logged in as. We did not have read-write access to the database. Logging on as a local administrator with full privilege to the database resolved this problem.
The second problem we had was to do with migrating subsites (not site collections). We found that you can only import them to a top sub level site – and only if you first create a blank sub site with the same name first. This is the opposite when importing site collections – you can import them without first having to create a blank site, and you can import them anywhere in the site (not just straight under the top level site collection).
So once you’ve got the thing successfully imported at a top sub site level, you can easily move them around using the 'Manage Content and Structure' GUI interface.
FYI, the syntax for an export is:
stsadm -o export -url http://myserver/mysubsite1/mysubsite2 -filename c:\backup.dat -overwrite
the syntax for an an import is:
stsadm -o import -url http://mynewserver/mysubsite2 -filename c:\backup.dat
Closer inspection revealed that although the export appeared to work (i.e. we got a success message), closer scrutiny of the export log shows that not all objects were correctly exported (in our case, some of the list definitions). This was due to the account that we were logged in as. We did not have read-write access to the database. Logging on as a local administrator with full privilege to the database resolved this problem.
The second problem we had was to do with migrating subsites (not site collections). We found that you can only import them to a top sub level site – and only if you first create a blank sub site with the same name first. This is the opposite when importing site collections – you can import them without first having to create a blank site, and you can import them anywhere in the site (not just straight under the top level site collection).
So once you’ve got the thing successfully imported at a top sub site level, you can easily move them around using the 'Manage Content and Structure' GUI interface.
FYI, the syntax for an export is:
stsadm -o export -url http://myserver/mysubsite1/mysubsite2 -filename c:\backup.dat -overwrite
the syntax for an an import is:
stsadm -o import -url http://mynewserver/mysubsite2 -filename c:\backup.dat
Thursday, February 22, 2007
MOSS 2007 - Strange Behaviours in applying Master Pages across subsites
I was at a client site today and we were experiencing the following problem:
When you create a sub-site underneath the home site and use say the 'Team Site' template, switching to the home site and applying a Site Master Page (with the children inherit option checked), this new site does not inherit the change. When you navigate to the new team site it complains saying 'The system master page setting currently applied to this site is invalid. Please select a new master page and apply it'.
The answer is:
All WSS templates that are also included in MOSS (including pages) actually inherit their setting from the System Master Page setting, not the Site Master Page setting. The Site Master Page is not used. Only in MOSS-specific templates, such as a Publishing site, is there Site Master Page usage and System Master Page usage. So to fix this, from the home page Master page settings page, select 'System Master Page' select the master page you want and check the 'Reset all subsites' option.
When you create a sub-site underneath the home site and use say the 'Team Site' template, switching to the home site and applying a Site Master Page (with the children inherit option checked), this new site does not inherit the change. When you navigate to the new team site it complains saying 'The system master page setting currently applied to this site is invalid. Please select a new master page and apply it'.
The answer is:
All WSS templates that are also included in MOSS (including pages) actually inherit their setting from the System Master Page setting, not the Site Master Page setting. The Site Master Page is not used. Only in MOSS-specific templates, such as a Publishing site, is there Site Master Page usage and System Master Page usage. So to fix this, from the home page Master page settings page, select 'System Master Page' select the master page you want and check the 'Reset all subsites' option.
Monday, March 27, 2006
The dreaded 'An error has occurred' message during SPS Install
I have never had this happen to me, but last week one of my colleagues had a monkey on his back when he was trying to install SharePoint Portal Server. The install failed at the point when the Configuration database was being created with 'an error has occurred'. To troubleshoot the problem I got him to install SQL Client Utilities onto the box (which he should have anyway to ensure the SharePoint Backup/Restore works properly) and then try to create a new database on the remote server. This failed. In the end we found that for some reason, the Model database in SQL was set to Single user mode and the dba was using that connection. Once we deleted his connection and set it back to Multiuser, the install worked without a hitch.
Ever wondered how to increase the size of the My Site Photo?
I had a customer the other week that wanted everyone's My Site photo to appear a little larger (so that vision impaired people could see it easier). Out of the box, SharePoint sets the maximum photo size to 100 x 100. If a photo is only 50 x 50, then it still gets rendered at 50 x 50 because SharePoint does not stretch an image to be larger than its original size. The average size of the photos that my customer was uploading to the Staff Image library was 300 x 200. SharePoint would shrink this image to be around the 100 x 66 resolution. To fix it, I modified public.aspx, which exists in the My Site template (C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033\SPSMSITE). I changed the text from:
<table cellspacing=0 cellpadding=0 style="table-layout: fixed" width="100" id="tablePictureUrl">
<tr id="PictureUrlImage_TR" height="100"><td id="ProfileViewer_ValuePictureUrl" valign=top align=right>
<SPSWC:ProfilePropertyImage PropertyName="PictureUrl" ResizeToFit="100" ShowPlaceholder="true" id="PictureUrlImage" runat="server" />
</td></tr>
</table>
to:
<table cellspacing=0 cellpadding=0 style="table-layout: fixed" width="300" id="tablePictureUrl">
<tr id="PictureUrlImage_TR" height="300"><td id="ProfileViewer_ValuePictureUrl" valign=top align=right>
<SPSWC:ProfilePropertyImage PropertyName="PictureUrl" ResizeToFit="300" ShowPlaceholder="true" id="PictureUrlImage" runat="server" />
</td></tr>
</table>
Quite simple really, changing '100' to '300'.
<table cellspacing=0 cellpadding=0 style="table-layout: fixed" width="100" id="tablePictureUrl">
<tr id="PictureUrlImage_TR" height="100"><td id="ProfileViewer_ValuePictureUrl" valign=top align=right>
<SPSWC:ProfilePropertyImage PropertyName="PictureUrl" ResizeToFit="100" ShowPlaceholder="true" id="PictureUrlImage" runat="server" />
</td></tr>
</table>
to:
<table cellspacing=0 cellpadding=0 style="table-layout: fixed" width="300" id="tablePictureUrl">
<tr id="PictureUrlImage_TR" height="300"><td id="ProfileViewer_ValuePictureUrl" valign=top align=right>
<SPSWC:ProfilePropertyImage PropertyName="PictureUrl" ResizeToFit="300" ShowPlaceholder="true" id="PictureUrlImage" runat="server" />
</td></tr>
</table>
Quite simple really, changing '100' to '300'.
Problems with running SPS install via Terminal Services
A colleague of mine ran into some problems last week while trying to install SharePoint at a customer site. They were connecting to a VM Ware instance via terminal services (mstsc) and were getting a VB runtime error whenever they tried to run setup.exe. After a couple of frustrating hours we realised that in order to run the install you had to be connected to the console session. The syntax therefore should be mstsc -v:servername /F -console where mstsc is the Remote Desktop connection executable file, -v indicates a server to connect to, /F indicates full screen mode, and -console is the instruction to connect to the console session.
Friday, March 03, 2006
Welcome
Well I never thought that I would see the day when I would succumb to blogging. I view people's blogs all the time, but rarely find time to work on one myself.
Who am I?
Well I'm the Australian National Manager for Collaboration & Workflow solutions for Strategic Data Management, a Microsoft Gold Certified Partner with offices in Melbourne, Adelaide and Sydney. Although I am a techo at heart, I also do a lot of sales & marketing related work, including client demos, creation of marketing material and bid work; oh yes - don't we love that bid work :-(.
As I specialise in all things Information Worker (and Business Process Automation), I will use this blog to post useful information that I have found around the traps. Hope you enjoy!
Who am I?
Well I'm the Australian National Manager for Collaboration & Workflow solutions for Strategic Data Management, a Microsoft Gold Certified Partner with offices in Melbourne, Adelaide and Sydney. Although I am a techo at heart, I also do a lot of sales & marketing related work, including client demos, creation of marketing material and bid work; oh yes - don't we love that bid work :-(.
As I specialise in all things Information Worker (and Business Process Automation), I will use this blog to post useful information that I have found around the traps. Hope you enjoy!
Subscribe to:
Posts (Atom)