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.
Subscribe to:
Posts (Atom)