A client pointed this out to me – Adobe Labs has released software that will allow the 32 bit Adobe iFilter to work on MOSS 2007 x64. It's a bit "hacky", but pretty Easy to setup. My guess is that Adobe was getting a lot of guff for not having this out so they had to throw us a bone in the interim.

http://labs.adobe.com/wiki/index.php/PDF_iFilter_8_-_64-bit_Support

MY BLOG HAS MOVED – check it out at http://www.ryan.mccutchenoutpost.com

 

One thing that vexed me initially, was that the Microsoft Architecture documentation clearly mentions this practice of separating Team Sites in a deployment scenario, and it is still a very sensible pattern. However, maintaining sites on a separate web app or site collection is not really an out of the box solution in MOSS (like it was in 2003). From a usability standpoint, some things need to be tweaked. I pinged several colleagues and discovered that none of them were separating out team sites in their deployments, which got me wondering about how the viability of this approach. Although, separating team sites into a separate web applications can give you several benefits.

Team sites are more adhoc, and well …"wild west" style in terms of portal governance. They are usually maintained by the business and not IT, and the business has free reign (to a certain extent) over what they do in their team site. My Sites share this model. Team Sites are also very organic in growth, and in many organizations where IT does not audit or control team sites other than provisioning, can tend to become very large high traffic sites with little IT oversight. Separating team sites into separate web applications and a separate app pool from the portal will minimize the risk of this governance model by having Team Sites on a separate SLA (Service Level Agreement) as well as isolation in IIS if things go bad with team sites. This makes sense from a high level architecture perspective to reduce single points of failure, but the reality is that team sites are the real bread and butter of SharePoint, and end users will be in much more of a crisis if their project site is down as opposed a policy in the document center, news or web content, or even enterprise search. So someone looking at the information architecture needs to do careful analysis on the capacity planning of team sites and how that ranks to the portal. Some organizations will be very thin on the "portal" side of a deployment with the majority of users focused on team collaborations while some could be the reverse…..initially. Most groups when deploying a new portal will focus mainly on the governance, design, and taxonomy of the enterprise portal side because that space is really IT's domain – that is where IT will have the control and the capacity to plan. But even if you are not meeting with every stakeholder in the company to determine their department or team collaboration needs (most teams cannot afford the time that analysis would take), do not under estimate the rate at which team sites will grow in your environment. When looking at this from a system availability or resiliency of the environment, you need to consider the practical side of what SLA's are really required, meaning, what functions are absolutely business critical and where do they reside.

I think a downside of this separation whether teams sites are in a separate web application or just all created under the Site Directory is the taxonomy limitation it can create. Creating a separate space for all collaboration to take place can have its advantages, but it can also create usability issues as users now have multiple choices of where to go, and they may not understand the distinction between a team site and the sub site in the portal. For example, say have a publishing site on the central portal available for the IT department that all employees can access, and you also have a team site that only IT users can access to get content internal to the department. Well say your ticketing system is on the enterprise IT site while your system documentation is on the IT team site. Now IT users have 2 separate places to go to do their job, and these 2 places may have different urls and or navigation paths. Is that necessary? With the right permissions model the IT users could see the all employee content and the internal content in department or project sites from the same site. Obviously if each department is it's own site collection than you can have this properly organized with less manual work, but if that is the case then what would be on this separate Team Sites web application? Most team sites can somehow relate back to a department. Otherwise what are users collaborating on?

I'm not saying that one way here is right or wrong, and each method depends on the specific deployment. I would recommend that during the planning phase their is a good amount of time spent on what collaboration means to the organization, and how that is properly blended into the overall taxonomy. If your deployment is small, set a quota on the parent site collection of 25 – 30 gb, and if it gets to close to the quota, analyze what sites are taking the most resources – and scale out to a separate web application if need be , but be cautious of over-architecting a solution and creating more of work around processes for enterprise search and leveraged metadata if it is not required.

MY BLOG HAS MOVED – check it out at http://www.ryan.mccutchenoutpost.com

Joel Olsen has a good post on prescan, and does allude to SP2's functionality. He mentions how to extract prescan out of sharepoint.exe (older post), but its easier to download it directly in you have not installed MOSS in an upgrade scenario – see post from Shane Young

stsadm -o renameserver -newservername <server name without fully qualifying> -oldservername <server name with the FQDN>

The service started right up for me after that. As always if this is a production environment….or any you don't want to screw up then do a back up first.

While this document wont really give you a "hand holding" type of experience on all the different tasks involved, it still gives you the ability to strip out a pretty good checklist of all the things you need to cover off on in order to create an up front costing / level of effort plan that will keep you much closer to the actual cost to deploy the MOSS platform to your organization.

For those you like me who immediately installs an app, and then begins to click wildly hoping for everything to work out should take note that the BDC Definition Editor DOES need to be installed on your web front-end server running SharePoint. Of course this is obvious to some, especially those who take the time to go through the READ ME file before jumping in, but I don't feel like too much of an idiot because I saw several posts on the interwebs of users complaining of issues with the tool, and no one mentioned this obvious fact. So I installed it on my dev box (without MOSS) and quickly discovered that I could not connect an existing web service, but I could get there from my browser.

If the app is installed on a box not running SharePoint, and you attempt to connect to a web service url when clicking Add LOB System,you get – "Error Downloading Web Service". Install the editor on my SharePoint box and life is good. I did see someone suggest that you can copy the wsdl file local, change the connection settings, and it will work, but I cannot verify that…..Just a tidbit for those like me who click first and read later.

Obviously the success on a portal deployment will heavily depend on communication and evangelizing your portal vision from a functional and technical perspective. But who should do that? IT? I know that personally, I have a hard time relaying technical stuff to non-technical people. We techies have a tendency to leave your average business user in a near comatose state as we blaze through all the sexy things that our applications can do. OK….so lets train them right. We'll sit our users down for a 3 day dive into our product. Which is all good and well from an IT project checklist perspective, but the users are walking away with about 5 – 10% understanding of the material that was covered. They will go back to their daily jobs without a second thought to your life changing portal. And then they will someday need to interface with your product as part of their job…..and that's when they call the help desk.

So how do you keep from helping that same old admin post a document for the 10th time? You pass that skill on to key users in your organization – Business Subject Matter Experts. However, this can be difficult given your SMEs will most likely not be techies either. Usually where this goes south is when people are assigned this duty. As part of a project, IT will tell the business to assign a SME within their division. Management will hand this honor down to some poor schlub who will have to take this on as a recreational activity on top of their daily job. So basically this will just create a level of abstraction between IT and the business. So now a user is calling the help desk on behalf of another user. SMEs in the business need support from their management – If management is not supporting these people then it will die on the vine. That's half the battle – the other is that your SMEs actually need to want the job. They need a passion for your product. This is hard to find – it is the Bigfoot of business users. To do this you need to seek out the passion. Look for glimmers of this passion in a business user and capitalize on it. You know you've seen it – Those users who call five times a day with questions….and are ecstatic when they get their issue solved. The users who ask you to recommend a good book for the product. The user who starts asking you when the next version is coming out. When you see this type of behavior, you may have a potential SME on your hands….and if this person is willing to sign up for the job then it is your job to turn this seed into a beautiful flower. Focus on these types of SMEs and your phone will ring less and less. This type of passion for a portal or application distributed to key users in the business will allow your strategic vision to be better realized. Information workers don't want a 10 paragraph email explaining a feature set, or even a long drawn out training class. They want someone 2 cubes down from them who they can ping whenever they hit a wall. With this grass roots or guerilla type training – end users will pick up features at a much quicker rate. Which of course is the lynchpin of any portal project – It can be the greatest technical masterpiece known to man, but will fail without user adoption.