In standard operating mode, I was pulled from both Team Server and BizTalk Server installation into Sharepoint based on some client needs. The work involved making brand customizations to thier Sharepoint Portal site.

I needed to make color and style changes to the portal site. I am not an artist, so my job was really to figure it out so their graphics person can make changes. I repeat that I am not an artist, and I am sure my color choices will be less than perfect.
In any event Sharepoint has a set of templates for various types of sites that it is capable of supporting.

Many files are repeated throughout the sets of templates. Depending on the type of site created, a different base set of template files may be used. All colors, many graphics, and some behaviors in sharepoint are guided by Cascading Style Sheets. For the portal as a whole, you are permitted to define a style sheet which will override styles. I have defined such a style sheet called "custom.css" at

file:////MySharepointServer/c$/Program%20Files/Common%20Files/Microsoft%20Shared/web%20server%20extensions/60/TEMPLATE/LAYOUTS/1033/STYLES

The custom style sheet now references some custom images as well. These images are all contained in the folder:

file:////MySharepointServer/c$/Program%20Files/Common%20Files/Microsoft%20Shared/web%20server%20extensions/60/TEMPLATE/IMAGES/Custom

This sheet affects the portal directly due to a configuration setting found in

Change Portal Site Properties and SharePoint Site Creation Settings under the Site Settings area for the portal.

For sites in the portal, the configuration method provided by the site administration tools is to apply a theme. Why you can't apply a set of style sheets, I don't know. A theme certainly includes style sheets, but oh well. You can create custom themes by adding a folder to

file:////MySharepointServer/c$/Program%20Files/Common%20Files/Microsoft%20Shared/web%20server%20extensions/60/TEMPLATE/THEMES

and then adding the theme information to

file:////MySharepointServer/c$/Program%20Files/Common%20Files/Microsoft%20Shared/web%20server%20extensions/60/TEMPLATE/LAYOUTS/1033/SPTHEMES.XML

This could be a good way to go if your artist wants to take the time, but it didn't utilize the work I had already done on the custom.css, so I went for a more stylesheet based approach.I placed my stylesheet references into the base template files for document workspace related sites at

file:////MySharepointServer/c$/Program%20Files/Common%20Files/Microsoft%20Shared/web%20server%20extensions/60/TEMPLATE/1033/STS

and its subfolders (esp. DWS and Lists).

Any template which has been customized via frontpage, and any additional pages added are not stored on disk, but rather in the database. In order to edit these pages, you have to go through a web folder (add as network place in network neighborhood folder). This methodology can also be useful for finding base templates because the web folder will show you url style locations you can match against where you are browsing. Looking for base templates on disk is difficult if you aren't familiar with the scheme and naming. Please note that making changes to base templates is liable to cause headaches on an upgrade or patch because these files will not be respected and may be overwritten. In order to change the file, copy it out locally, change it, then copy it back to the web folder.

For the site templates I also had to create a subordinate style sheet which I called "customSite.css". This was required because some changes conflicted with the custom.css on the main site. The css inheritance model has ows.css, then sps.css going first on the portal site, then your customizations in custom.css (or whatever you called yours). On the sites, you only have ows.css. If I put the all the customizations required for sites directly into custom.css it behaved badly in the portal. So in sites i added another to inherit below custom.css, and thus override certain portal only custmizations. The inline stylesheet references are:

<link REL="stylesheet" type="text/css" href="/_layouts/1033/styles/custom.css">
<link REL="stylesheet" type="text/css" href="/_layouts/1033/styles/customSite.css">

The accepted practice in the base templates is actually to make the localization code a dynamic number as such:

<%=System.Threading.Thread.CurrentThread.CurrentUICulture.LCID%>

This works in the templates, but will not work in the customized files retreived from the database.

The short of it is;

• If you want to change the images: change them in the custom images folder.
• If you want to change which image and any color: change the css files.
• If you run into a file which you would like to add the custom styles: then add the custom stylesheet references to the base template.
  

There are some excellent resources at the following sites:

http://blog.hishambaz.com/archive/2005/01/29/196.aspx

http://weblogs.asp.net/erobillard/archive/2004/09/24/234060.aspx

http://www.sharepointcustomization.com/resources/whitepapers_d.htm

http://office.microsoft.com/en-us/assistance/HA011608361033.aspx

Ok, so i haven't gotten any further on BizTalk walkthroughs now that it is installed and configured. Hopefully I will have some time soon. However, in between client projects I have been noodling with Visual Studio Team System (Team Foundation Server) installation and configuration.

First, Visual Studio improvements (and attendant .net framework changes) are awesome. The productivity enhancements are first rate, and really demonstrate serious developer input. As I get into more of that, hopefully I can spend time talking about it here.

On with Team System. I did a 2 server install (data and application) in a Windows 2003 domain. First annoyance is that reporting services seems to have to install directly on the box hosting SQL Server 2005. This is totally unncessary from a configuration perspective, so hopefully its a beta thing. It seems that MS methodology is going toward the application centric db that has a web server for web services. I suppose this makes some sense, but I can't get past my ingrained disklike for the mixing of these tiers. Extra config, extra security issues, extra blending of roles that confuses configuration. In any case, after installing IIS and Sharepoint services on my SQL Server I installed the data tier package. Easy enough. No problems.

I then installed the application package on my web server, and pointed it to the reporting server. Again, pretty smooth. I installed everything with the TFSInstall user, and made that user Admin on both boxes. This user is also setup to run the services, and the apppools, and the login to the reporting data sources. I will attempt to wean from this as configuration expertise increases. After the install completed and the reporting service seemed to work, and the web services on both boxes functioned, I removed theTFSInstall user from the admin role. To do this, I needed to give the user write access to %SystemRoot%/Temp, and to the temporary asp.net file folder in the framework folder so the appPools would function. I also gave the user permissions in the proper roles on the database, and database reporting service. I would be defeated in what seemed like an early victory very soon.

So, now the fun of configuration of the Team System from VS 2005 on my client machine. Opening the Team Explorer, I found and connected to my Team Server. Viola, so far so good. Then I selected "Create Project". I answered the wizard questions, and hit failure pretty quick. Unable to download the agile template. After some digging I found this was probably permissions related, so I gave TFSInstall its admin role again. Of course, the project could now be added without incident.

More later...

Just sent my most recent homebrew - a simple smoked porter - to secondary fermentation. gravity reading was .020, so I'll give it another few days and check again. Tasted pretty good, but this one will need a few months in the bottle to be worthwhile.

Installing BizTalk Server 2004

I recently embarked on the adventure of installing BizTalk in a distributed environment. I setup the application on 3 servers - all running Windows Server 2003 SP1:

Stand-alone SSO Server
Engine/Rules Server
Database Server (all databases)

The servers all live in a single AD Domain. Users live in the parent domain (currently i don't have any users - as I just installed).

Here are a few things I ran into...

Setup actually went fine, but configuation of the engine server was a bit difficult due to MSDTC setup issues, and a few BizTalk group permissions issues related to SSO. These are the types of issues you can solve in a few minutes if you know where to look, but took me several hours to discover and resolve.

First, DTC - I believe the documentation with BizTalk is lacking in readability, but does mention the basics here.

• You must allow network DTC via the option under Add/Remove programsWindows Componentsapplication serverEnable Network DTC Access. Reboot required. http://support.microsoft.com/default.aspx?scid=kb;en-us;817064
• DTC service must have good network access on a broad range of ports. http://support.microsoft.com/default.aspx?scid=kb;en-us;306843

After this, issues tend to be permissions related. I needed to make the registry hack to turn off DTC security:

http://support.microsoft.com/default.aspx?scid=kb;en-us;839187

For SP1, the DTC configuration editor has been enhanced, and you may be interested in that information, though I didn't have to make any changes here...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/2627a956-60b3-4d26-bc04-e0676ec97786.asp

Finally, for testing DTC I used DTCTest and DTCPing

http://download.microsoft.com/download/e/a/2/ea20a97f-672d-4826-8e52-1e83e7d9ddfb/dtcping.exe

http://download.microsoft.com/download/b/8/8/b8841bfc-8bd3-4fea-a5f5-06e1f162bd9a/dtctest.exe

OK, with DTC working, the configuration began to fail on a permissions issue. Which, once I looked into the application event log (never forget about your event logs), was quite clear. The setup user was not authorized in SSO. This is clearly stated in the docs, I just missed it. The user performing the setup has to be in the SSO Administrators group.

To be sure, I was a bit unclear from the docs about all the groups, and if in a domain or local how they had to be setup. I created the 2 admin groups (BizTalk and SSO) both in the domain, and on each of the 3 servers. I pointed the local groups to the domain groups, and added my parent domain account locally on the installation server only. During configuration all groups were pointed to domain groups, and these other groups were created only at the domain level.

I created 3 users in the domain - an SSO service account, a biztalk general services account, and a biztalk host account. The biztalk services account was in all groups, the sso account in the SSO admins group, and the host account in the 2 host groups. During configuration the 2 biztalk domain accounts were specified for the appropriate services.

Finally, I did make a couple of changes to the SSO server, but I don't think they actually made anything work. However, I think the documentation is lacking here. The SSO administration tools are in the program files/common files/enterprise single sign-on folder. I used

• ssoconfig -backupsecret to create a master key backup
• ssomanage -serverall to set the SSO server for all users (this seemed helpful, but not sure)
• various ssomanage listings to see the state of SSO installation.

That got me through installation and configuration. Now, I am off to try and follow along with the tutorial.

Hello, and welcome to my first blog entry.

I am interested in blogging primarily as a simple way to record the information i come across in daily life, both at work and at home. I am happy to share the info, and also hoping that recording it is useful for me as well.

I have a website at http://jeffgabriel.com (which is currently dedicated to homebrew) where I could have installed blog software I suppose, but figured this would do for now.