After tinkering for over a day, I think I got it figured out. My farm configuration is as follows:
Port 80 : Collaboration Portal
Port 81: My Sites
Port 100: Central Administration
Port 103: SSP
Troubleshooting Steps
When I tried to connect to Port 81 as the Source URL I would get one of the above errors. Same thing when trying to connect to the SSP or Collaboration Portal as the source URL. I then proceeded to tear down my SSP and My Site Host a few times (on a dev box) and eventually rebuilt my My Site Host to be on Port 80. After I did that it finally worked. The bad news is that I didn’t have the luxury of tearing down the SSP and My Site Host in the production environment where I had to do this stuff. So I moved my My Site host back to Port 81, tried the User Replication Tool again and noticed that it was still working when using Port 80 as the source URL.
What was it?
The User Replication Tool seems to be looking for the “userprofileservice.asmx” web service on port 80 no matter which web application is hosting the My Sites. For some reason or another my port 80 didn’t have the proper web services in it. After resolving that issue, I also noticed that it still won’t work with port numbers in the URL. For example http://localhost works but http://localhost:81 doesn’t work even though the My Sites are hosted on port 81. I validated this by renaming the web service on Port 80 and used Port 81 as the source URL which still generated the error.
Another Error…
After getting the Configuration Tab all set up, I went over to the Full Replication tab to do an actual replication. I was once again presented with the “Cannot access Web Service” error. This time around I didn’t feel like figuring out what the root cause was and instead tried running the application as the app pool account and then it worked!
Wowzas! This conference was packed with so much information about the new SharePoint 2010 features that my head nearly exploded. In my opinion Microsoft actually proved to us that they do listen to the voice of the customers and in particular the SharePoint community. This was proven session after session with presentations (levels 1-400) covering breadth and depth across everything that is going to be SharePoint 2010 even before the public beta is released! Alright, enough of that mumbo jumbo – here’s a list of features that I am definitely looking forward to, how they had evolved and how you’ll be able to utilize them for your business.
In no particular order…
Cross-Farm Managed Metadata Services
Previously metadata definitions and properties were handled through the usage of Content Types. That was a good thing but unfortunately the scope of a Content Type did not span across Site Collections! That proved to be quite a barrier for enterprise taxonomy folks especially when they also had to take into consideration best practices like content database sizing, site structures and information sharing. Going forward metadata can now be managed as an enterprise wide service. What that means is we will no longer have to figure out how to sync Content Types across disparate Site Collections and even across disparate farms within the enterprise. That’s taken care of by the Managed Metadata Services.
FSHTTP and other New Protocols
In SharePoint V3/2007, documents that are uploaded and downloaded from SharePoint Document Libraries are transferred as the entire file. This is an issue not only for large files on the local LAN but proved to be extremely detrimental for geographically dispersed environments with unpredictable latencies to the client. SharePoint 2010 along with the Office 2010 Clients introduce some new transfer protocols that will greatly reduce the amount of traffic that gets passed from the client to the web front ends. This is done through the new FSHTTP protocol and what it basically does is only transfer the document deltas to and from the server with the help of local client caches.
The Client Object Model
I actually have mixed feelings about this one. It greatly enhances the flexibility of the Object Model to be able to interact with JavaScript, WPF, SIlverlight and other remote applications enabling them to interact with SharePoint List Data (and other data). Where I’m a little weary about this awesome new power is… with great power comes great responsibility! While this lowers the entry barriers for developers of other disciplines (Silverlight devs, Javascript devs, WinForm devs, etc.) to more easily work with SharePoint, this new wave of developers using SharePoint as an application development platform will have to quickly learn to be cognizant of the yet to be determined pitfalls and best practices. This will also put great pressure on the infrastructure teams to keep an eye on stability and performance metrics which leads me into the next cool feature…
The Developer Dashboard and Resource Throttling
All I can say about this is sweeeeet. There’s no longer a need to question the performance of a customization nor wonder how out of control customizations can be controlled. The Developer Dashboard gives both developers and administrators the ability to look at very specific key performance indicators to help them zone in on specific operations of the application that is not performing up to par. With this kind of insight, the team can decide whether or not to try and optimize the code or even perhaps throttle some of the resources being used, like the return size of SharePoint List queries.
Business Connectivity Services
Formerly Business Data Catalog, I would consider this new feature quite revolutionary. The idea may not be revolutionary in itself but the integration and ease of use provided by SharePoint Designer 2010 really knocked my socks off. Currently many organizations have been wanting to surface information from their legacy or line of business systems but may have found it difficult to create and configure BDC definitions for MOSS 2007. With SharePoint Designer 2010, you’ll be able to click through some very intuitive wizard interfaces that will create External Content Types that can be used by a native SharePoint List interface to create, read, update and delete data that is stored in any non-SharePoint content database. Now that is huge! But there are some drawbacks – SharePoint workflows, events receivers, and a few other native functionality will not be available for these kinds of lists. In that case you’ll want to handle that logic at the data level as SharePoint is only being used as a user interface.
Now those were just some of the new and upcoming features coming to SharePoint 2010 that caught my attention. I’m sure I’ll be coming across plenty more but until the beta release in November, I’ll leave you with some pictures I took (mostly notable slides I wanted to remember).
You’ve built a centralized help desk/issue tracking system within your intranet site for all of your employees to use. There are also personalized views for this list (based off of a SharePoint Task List) so that your internal customers can view status updates on their tickets whenever they want. You also have a bajillion extranet sites you have to support but you don’t want to give those extranet users access to your internal issue tracking system/list. But you do want them to be able to see the status of their tickets and be “social” with it from their respective extranet sites. What do you do?!
Possible Solutions
1. You could have a custom web part on each extranet site that queries and renders the appropriate tickets from the main list…. that could be a lot of querying going on, performance issues…
2. Write some kind of custom workflow that copies the ticket information to a similar list on the extranet site… that sounds complicated…
3. Create a workflow that sends an email to an incoming-email enabled list on the extranet site… too much management overhead & can’t separate email text into columns/views…
4. Create a workflow that sends an email to an incoming-email enabled discussion board on the extranet site… hmm, interesting the message would show up in the body… but we couldn’t control the metadata…
5. Create a custom event receiver to replicate the ticket in a list on the extranet site… hmm, that sounds like #2 and not very “social”.
6. Create a custom event receiver that writes the ticket information to a discussion board thread on the extranet site and replies to the discussion thread when ticket information is updated. Hmm, this sounds interesting. I can write to any column I want in the discussion board… I can update the thread so that users can reference later… users can reply using the discussion board… ding! ding! ding!
Solution Overview
I don’t know about you but I kind of like that last #6 idea. So I modeled it out and this is what I got:
Here’s some food for thought if you’re developing custom SharePoint solutions that involve Visual Studio. These are just some things I’ve picked up along the way so feel free to comment if you’d like.
This is a much debated topic and further research should definitely be done on the merits of each approach when determining which method of code deployment should be used in deploying custom SharePoint DLL’s.
Using Code Access Security will introduce more elements of complexity to your custom SharePoint solution but may also be required in some environments. With that said, some custom SharePoint solutions will require that the code or DLL’s are deployed to the Global Assembly Cache (GAC) in order for it to even work in a SharePoint environment. This essentially renders the need for CAS irrelevant in some cases (I think?). Some examples of these special cases are workflows and event receivers. There are some other cases but I can’t remember them off the top of my head at the moment…
Deploying your code to the Global Assembly Cache is the easiest and most rudimentary way to deploy your code. For solutions such as custom web parts, this may be ok but in others this may not be acceptable. An example where this might not be acceptable are environments where the server is a shared resource amongst disparate organizations and code sharing should be prevented. To expand on that, consider if you had a custom web part that is configured to tap into some secret data sources that one organization can see but other organizations on other web apps on the server should definitely not be able to use it. Unfortunately, when code is deployed to the GAC, any web app will be able to activate the feature and execute the code.
A hybrid approach is to deploy the DLL to the web application’s BIN directory, much like you would when using Code Access Security, but you would also set the trust level of that web application to “Full” from the standard “WSS_Minimal.” Changing this trust level is analogous to deploying the code to the GAC whereas the code is fully trusted by the server, but having the DLL in the BIN adds a level of inaccesibility by other web applications. This is my current preferred method for deploying customizations since it gives me more flexibility in properly scoping my solutions and at the same time not as complex as having to implement CAS for everything.
So you think you can haXor 32-bit SharePoint by using Windows 2003/2008 Enterprise eh? Guess again…
Although I haven’t been really able to find a definitive Technet/MSDN article on this issue anywhere, I have come across some tidbits of information that suggests otherwise. Just because the 32-bit Enterprise versions of Windows Server 2003 can support more than 4GB of RAM by way of the /PAE switch, that doesn’t mean 32-bit SharePoint can take advantage of that extra memory.
Back in November ’08, I was on a troubleshooting call with MSFT support. We had asked them about the option of using either the /3GB or /PAE to improve SharePoint performance and they had responded with a negative. Here are some links I’ve come across to reaffirm this fact:
Thursday, November 20, 2008 5:48 PM by MattMossDeveloper # re: Dealing with Memory Pressure problems in MOSS/WSS
Stefan,
Would it be possible to get your sharepoint w3wp to use more memory if you had a windows 2003 enterprise server (8 gig ram) with PAE enabled?
Thursday, November 20, 2008 5:58 PM by Stefan_Gossner # re: Dealing with Memory Pressure problems in MOSS/WSS
Hi Matt,
no this will not help. PAE allows a computer to address more physical memory. Not more virtual memory.
The virtual memory of a process is always 4GB. 2 GB system and 2 GB user mode RAM.
So PAE would allow you to run more processes without a need of paging. But not to address more memory within a single process.
Cheers,
Stefan
Reducing the size of the kernel mode memory buffers when in /3GB mode causes unacceptable performance in Windows SharePoint Services file-transfer operations. Therefore, a decision was made not to support the /3GB switch in Windows SharePoint Services. Windows SharePoint Services will run if you use the /3GB switch. However, the operating system will become unstable in scenarios in which the server is under stress.
My best guess is that the 32-bit SharePoint code base was not developed to support AWE which is a requirement for PAE compatibility.
AWE is a set of application programming interfaces (APIs) to the memory manager functions that enables programs to address more memory than the 4 GB that is available through standard 32-bit addressing. AWE enables programs to reserve physical memory as non-paged memory and then to dynamically map portions of the non-paged memory to the program’s working set of memory. This process enables memory-intensive programs, such as large database systems, to reserve large amounts of physical memory for data without having to be paged in and out of a paging file for usage. Instead, the data is swapped in and out of the working set and reserved memory is in excess of the 4 GB range. Additionally, the range of memory in excess of 4 GB is exposed to the memory manager and the AWE functions by PAE. Without PAE, AWE cannot reserve memory in excess of 4 GB.
I don’t argue the merits of /PAE for operating systems though. Unfortunately it doesn’t seem to be relevant for today’s 32-bit SharePoint environments. Anybody want to argue otherwise?
For those of you that still have to deal with Office 2003 in a MOSS 2007 environment, here’s an error that had caused a couple weeks of grief as I worked with 5+ different Microsoft Support Engineers to figure out. You would think that Microsoft would have a catalog of these error messages and what they mean but apparently not as we had to figure this out the hard way through trial and error.
Error Message:
Another user has changes the structure of the list. Your changes can no longer be published to the SharePoint list.
Root Cause Analysis:
The error occurs when the user has a spreadsheet that is out of sync with the SharePoint List. When this spreadsheet contains an item that had been deleted from the List and the user tries to update the item in the spreadsheet with new values, it will cause the error. If the item was not modified in the spreadsheet, it will sync without error and remove the item from the spreadsheet to match the SharePoint List. Also the List will be properly updated in the SharePoint List regardless of whether or not the error occurs. If new items are added to the SharePoint List, the spreadsheet will be updated accordingly without error.
To reproduce:
1. Export and link the List to Excel 2003.
2. Delete a List Item from the List.
3. From Excel 2003, try to update the same exact item that had been deleted. Sync the spreadsheet back to the SharePoint List.
One of the presenter’s scheduled for last week’s SharePoint User Group meeting here in the L.A. area was sick so I and a coworker filled in last minute with an impromptu discussion on “The Good, The Bad, and The Ugly” about SharePoint Site Templates. Doing a tag team presentation was pretty fun and I think much more entertaining for the audience. No wonder you’ll never catch Bob Fox doing a presentation solo… J/K. Most of it really was a conversation with everyone so if the slides don’t do it for you, you’ll just have to try and make it out the SPUG sometime!
What do you think are good or bad things about using SharePoint Site Templates?
I thought I was losing my marbles not being able to remember what roles did what for a SharePoint Site Collection based on the Publishing Portal Template. Better write it down before I forget again… Feel free to add comments!
By default, an OOB SharePoint Site Collection based on the Publishing Portal Template contains the following groups in order of most privileged to least:
Site Collection Administrator
Members of this group have untethered access to all resources within the Site Collection and also supersedes the Owners group.
Publishing Portal Owners
Use this group to give people full control permissions to the SharePoint site: Publishing Portal
Hierarchy Managers
Members of this group can create sites, lists, list items, and documents.
Designers
Members of this group can edit lists, document libraries, and pages in the site. Designers can create Master Pages and Page Layouts in the Master Page Gallery and can change the behavior and appearance of each site in the site collection by using master pages and CSS files.
Approvers
Members of this group can edit and approve pages, list items, and documents.
Publishing Portal Members
Use this group to give people contribute permissions to the SharePoint site: Publishing Portal
Publishing Portal Visitors
Use this group to give people read permissions to the SharePoint site: Publishing Portal
Quick Deploy Users
Members of this group can schedule Quick Deploy jobs.
Restricted Readers
Members of this group can view pages and documents, but cannot view historical versions or review user rights information.
Style Resource Readers
Members of this group are given read permission to the master page gallery and the Restricted read permission to the Style Library. By default, all authenticated users are a member of this group. To further secure this site, you can remove all authenticated users from this group or add users to this group.
Approver Roles
The minimum rights that a user will need in order to approve content is ‘Member’ and ‘Approvers’.
All Other Roles
Note that the following roles are scoped at the site level and can be recreated or inherited for each new subsite that is created:
Site Owners
Site Members
Site Visitors
All other roles occur only once per Site Collection.
Content Management & User Roles for Subsites
When creating subsites, you have the ability to:
Inherit permissions from the parent.
Use unique permissions.
When using unique permissions, the minimum role that a user must have in order to generate content is to be a ‘Member’ of that site. The minimum roles that a user needs in order to approve content is to be a ‘Member’ of that site AND to be a member of the ‘Approvers’ group at the Site Collection Level.
Some of you guys probably already figured this out but I haven’t built a new farm in awhile and this got me scratching my head so I thought I’d write it down so I don’t forget again.
Environment
2 Server farm (1 WFE, 1 SQL)
Windows 2008 STD for both (basic configurations)
WSS v3 SP2
SQL Server 2008
Scenario
After installing the WSS bits, I run the SharePoint Configuration Wizard to create Central Admin. After submitting the database server, name and credential information I get the following error:
An exception of type System.Data.SqlClient.SqlException was thrown. Additional exception information: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server)
System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server).
Resolution
The TCP port to the SQL Database Engine is blocked by the Windows Firewall. Create a new rule to allow inbound traffic to port 1433.
The SharePoint Swiss Army Knife 
You must be logged in to post a comment.