Dooly's Domain

Installing SharePoint on a "non-standard" SQL Port

2011-10-31T15:13:00.000-04:00

Attempting to install SharePoint on a "non-stardard" port can be a challenge. Typically a Database Administrator will not run SQL on the standard port for security concerns. Additionally, you might be attempting to install SharePoint on a Cluster and attempting to connect to the Cluster Port where your instance of SQL is being hosted.

The "non-standard port" creates a challenge for SharePoint Administrators and the SharePoint Installation. The SharePoint installation is looking for SQL Server on the Standard Port (1433).

An option that I've used and found to be very effective is the creation of a SQL Server Alias on each server in the farm. It's never bad, in my opinion to alias your SQL Server connection. You never know when this will be helpful in the future, specifically in the case of a database migration or hardware refresh.

Steps to create a SQL Server Alias:

Open SQL Server Client Network Utility. (I believe this tool is native to Server 2003, 2008 and 2008 R2).
Click on the Alias tab
Click Add

Server Alias: "Enter the Alias information (eg. "SPDatabase")
Network Libraries: TCP/IP
Server Name: "Enter the name of the SQL Server you where the Databes will be hosted"
Dynamically Determine Port: "Uncheck to enter a specific port, or leaved checked to dynamically determine port

Notes: If you leave "Dynamically determine port" checked, your Database Administrators can do some magic on their side to forward requests from a specific account to a specific port.

You'll need to recreate these steps on all the servers in the farm.

SharePoint 2010 - Uniquely Secured Content

2011-10-24T15:39:00.000-04:00

A very nice feature from SharePoint 2010 is the visibility into site content. I can't even count the number of times I've received the question from users "I gave them access to my site but they still can't see the list!".

There's a simple explanation for this. Inheritance is broken and "The List" has unique permissions. Unfortunately the Technology Team, more often than not, needed to get involved to communicate to with the user. For the more seasoned business users, the next question would be "So what do they have access to?".

Great question and a great answer for SharePoint 2010 to solve this problem?

Under Site Permissions, you have the option to see content with Unique Permissions. Click on the link "Show me uniquely secured content".

Show me uniquely secured content

Microsoft has really been listening to our Admistrative Challenges and gave a great and simple way to continue to empower the users. Once clicking on the link we can see what's uniquely secured. In the screen shot below, "Site Collection Images" and "Style Library" have unique permissions and are not inheriting from the site.

Docs and Test contain item level permission in side the libraries which is defined with "Lists that may contain items with unique permissions". It's a little bit misleading because Docs is a document library, but let's focus on what's important: We have better visability into our busines content and can better share those insites with our clients.

The Search Service is not able to connect to the machine that hosts the administration component.

2011-07-08T09:02:00.006-04:00

I've seen many posts about people who are trying to deploy the search service and are receiving this message. Unfortunately most of the solutions I've see say "Rebuild the farm", "Delete the service and start over" or some other doom and gloom scenario. I've found something that seems to be consistently missed - PERMISSIONS

When the Search Administration Web Service for Search Service Application component is created, it is only granted access as Local Farm - Full Control. Basically if you're not creating the Search Service as the Farm Account, you will see this message.

Never fear! There is a very easy fix. Give your installation account permissions to the Search Administration Web Service for Search Service Application.

This will prevent you from having to delete the service, rebuild your farm and lose your sanity.

CRM 4.0 Login Fails - CRM Expired Keys

2009-05-19T16:08:00.009-04:00

I received reports that users could not login to CRM. They would attempt to open the CRM site and would immediately receive an error. All users, even the Deployment Administrators were not able to open CRM.

The Event View Application log had lots of error with Source: MSCRMKeyGenerator / Event: 18949

Inside these errors I found the following:

Current active key (KeyType : CrmWRPCTokenKey) is expired. This can indicate that a key is not being regenerated properly. Current Active Key : CrmKey......

Quick fix:

Make sure that the "Microsoft CRM Asynchronous Processing Service" is started and then restart IIS.

Basically this service is pretty important for a couple of reasons. Long story short, make sure it's started and if it's not started, you'll need to restart IIS after starting it.

If the Microsoft CRM Asynchronous Processing Service won't start, you either have a locked out user account (hopefully you're running as a domain user account and not Network or Sytem), or you have another problem fixed in the latest cumulative update rollup for Microsoft Dynamics CRM 4.0

Reference - http://support.microsoft.com/kb/949844#appliesto
Cumulative Update - http://support.microsoft.com/kb/949256/

Can't see MOSS Workflows

2009-03-26T15:46:00.004-04:00

So I've recently ran into a strange situation. There are workflows created with SharePoint Designer and the Workflows option is not available for some users. After doing some more investigating I found that for certain sites in a site collection, only the Site Collection Administrator could even see the previously created workflows or add new workflows.

The inheritance on the site has been broken and fractioned all throughout the site. I haven't found a link to the SharePoint Designer workflow permissions through the SharePoint Site directly, but I have found a workaround.

1) Open SharePoint Designer > Right Click on Workflows and Select Properties.

2) In the Document Library Properties Windows, Select the Security Tab.

3) Select the "Manage permission using the browser" link
4) You'll need to adjust the permission for the appropriate SharePoint Users/Groups or Domain Users/Groups, depending on what you're using.

I've seen this happen to a couple of sites, and mostly appears to be caused very specific and custom permissions applied, which breaks the inheritance, and then the workflows are created by Site Admins or even Farm Admins.

SoapException. Error: The item '/Organization_MSCRM/4.0' cannot be found.

2009-03-11T16:34:00.007-04:00

I ran across a default installation of CRM and found a couple of issues with Reports and more specifically Reporting Services. Users are trying to create a report with the Report Wizard, inside of CRM.

Here is the error in the Application Log of the CRM Server:

Web service request SetItemDataSources to Report Server http://SERVER/reportserver/ReportService2005.asmx failed with SoapException. Error: The item '/"Organization"_MSCRM/4.0/MSCRM_DataSource' cannot be found.

If you are seeing this error message your more than half way there to getting your reports configured. You should verify your Reporting Services URL for CRM. You can do that by going here. What this is telling me that is that you are actually uploading the report but it doesn't see the CRM data connection and is using the default data connection at the root of the folder. If you look at the Report Manager site you should see your report. If you click on Show Details, and edit the report, then click on "Data Sources", you can get some insight to what is going on.

If your data source says "Adventure_Works" you don't have your default data connection setup for Reporting Services. The other possibility is that your folder structure isn't want CRM expects it to be.

Make sure that your folder structure for in Report Manager is "Home > Organization_MSCRM > 4.0" or whatever your CRM installation is complaining about. To resolve the directory structure, simply create new folders with the appropriate names.

Try to create your report again. If you're still having issues, go back to Report Manager and create a Data Connection.

Name: MSCRM_DataSource
Enable: Check
Connection type: Microsoft CRM Data Extension
Connect using: "Credentials supplied by the user running the report"

This data connection should be configured programatically for your, but i've seen cases where it hasn't.

CRM 4.0 and Reporting Services

2009-03-11T16:08:00.009-04:00

I've run into some issues recently with CRM 4.0 and Reporting Services. This is a recent installation of CRM 4.0 and this was not an upgrade. I have my CRM and SQL Server 2005 with SSRS all on the same server. I'm using a Host Header for the CRM site and the Server Name for the Reporting Services URL.

My user started reporting this error attached in the screen shot. This isn't a very informational error message, so I needed to do some investigating.

I found errors in my Application logs on my CRM server. That pointed at the Reporting Services URL.

From the application log:

Web service request CreateReport to Report Server http://%22report%20server/ReportService2005.asmx failed. Error: The request failed with HTTP status 400: Bad Request.

This error is because of the Reporting Service URL configuration in CRM.

To resolve this do the following:

1) Start > Programs > Microsofto Dynamics CRM > Deployment Manager.

2) Select Organization, then Select your Organization.

*Note: This next step will cause an interruption for your users.

3)Select Disable your Organization and then select Properties

4) Under the Microsoft Dynamics CRM SRS Data Connection URL, Change the URL to http://SERVER/reportserver

*Note: "SERVER" should be the web server where reporting services is being served from.

5) Click Ok, and Enable your Organization again.

6) Restart Reporting Services Application Pool

You can test your changes by hitting http://SERVER/reportserver and you should see basically a blank page that says Reporting Services.

Microsoft Office has identified a potential security concern

2009-01-17T19:16:00.007-05:00

I'm sure that I'm not the only one that has been prompted with this wonderful Warning. Unfortunately I did some searching and nobody out there seems to care. Everything I found pointed to "don't worry, it doesn't hurt anything".

I had issue with just accepting that was good enough. I've also had users complain that this was misleading.

I tried to add urls to Internet Explorer's Trusted Sites and still had no luck. What I ended up discovering was that office was actually checking for this warning and completely ignored the trusted site. Some of it was the content is simply handled different by Office, such as .WMV files. Trying to link to a .WMV file from Outlook or a Power Point presentation was prompting for this warning.

To resolve it, this is what I found:

HKU\"user account"\Software\Policies\Microsoft\Office\12.0\Common\Security\DisableHyperLinkWarning = 0

Setting the key "DisableHyperLinkWarning" to "0" will prompt with the Security Warning. Setting the same key to "1" will suppress the prompt and make everyone happy.

There are a couple of issues to be aware of. If the content is disabled, like macros or blocked file extends, they will still be blocked. This will also apply to Word, Excel, Power Point, Outlook and Access. This won't fix InfoPath, and I haven't had a chance to test the other Office related products.

Update:

I don't think i posted the registry clearly enough.

HKEY_USERS\"User Account SID" \Software\Policies\Microsoft\Office\12.0\Common\Security\

You'll probably need to create the Red_DWORD called "DisableHyperLinkWarning". It will have a value of 1.

Customizing SharePoint Top Navigation Menu and Quick Launch Bar

2008-10-23T18:01:00.003-04:00

Customizing SharePoint Top Navigation Menu and Quick Launch Bar has been a request from a couple of different sources. So I've decided to finally post on the logic, step and simply value changes to accomplish this. You will need a text editor for editing the master page and/or pages. For this I'll be using SharePoint Designer.

Goal:

Essentially you want to keep your main portal page clean and you want the "fly-away menu" look and feel. This is a major advantage with SharePoint 2007 and the Security Trimming. Depending on how many levels you want to show will determine your overall look and feel. Remember that you can look under your Manage Content and Structure under Site Actions to look at this tree and understand your levels. 0 (zero) is Home, and everything incrementing from 0 (zero) will allow for additional sub sites to be displayed.

Prep Work:

Under Site Action > Site Settings > Modify All Site Settings you'll see "Look and Feel". From here you're looking for Navigation. Under Navigation make sure that "Show Subsites" is checked.

NOTE: It is VERY important to make a copy of this original file > Default.Master . Changing the master pages can cause a lot of headaches for you and your portal, if not done correctly. I'd recommend even downloading a copy to another location for safe keeping. You can use version control, but I'm still recommending.

Use the breadcrumb to get back to Site Settings and under "Galleries" you are looking for Master Pages and Page Layouts > default.master.

Editing:

Find default.master and select "edit in Microsoft Office SharePoint Designer" or which ever editor you have installed.

First you're going to be looking for : "TopNav"

And more specifically 2 separate lines for editing:

StaticDisplayLevels="2"

MaximumDynamicDisplayLevels="1"

This is where the values determine the depth and width of your menus. The StaticDisplayLevels will determine how many levels in your site collection you wish display on the top ribbon and how wide you want it to be. For example, if you have "Home > Sites > Team Sites > Sub Team Sites > Sub Sub Team Sites" and your StaticDisplayLevels was set to 3 you would show everything up to "Team Sites" across the top. If you set your StaticDisplayLevels to 1, you would only show "Home". You can play with your changes and test. Just make your value change, save and then refresh your browser.

Second you're looking for: "QuickLaunch"

Same rules apply here but you're working on the horizontal expansion rather than vertical. You still have your same fields but your default values are a little different.

StaticDisplayLevels="1"
MaximumDynamicDisplayLevels="0"

Things to be aware of:

Security trimming does still apply here. If you can't navigate through a site you don't have access to. This translates to if you have access to sites #1, #2 and #4, your navigation will only show #1 and #2. You can't traverse through #3 to get to #4 so the menus will not show #4.

MOSS - This List not returning Search Results

2008-09-26T09:59:00.001-04:00

Symptoms:

You can't search lists or libraries in MOSS 2007. Or some older lists return results but nothing new. Essentially "This List:" doesn't return results while searching, but "This Site:" does return results.

There are a couple of possibilities here for the cause and I've read some ridiculous theories on this. Most of them point as your SSP being corrupt and you need to create it. Or you've corrupted your databases and need to restore them.

Really the first place I thought to check was Authentication. I found that there 2 different types of content in Sharepoint / MOSS 2007. Long story short, you can search the .aspx pages, separately from List and Library items. I've found this to be reflected in your indexes also.

What actually triggered this for me was resetting SPN's for Sharepoint. I found that some of the SPN's were throwing errors on the Domain controllers so I deleted and recreated them. In another case I changed from Kerberos to NTLM authentication to resolve some immediate issues but didn't update my search service account.

Fixing "This List" search issues:

1) Login to your SSP
2) Under Search, select Search Settings.

You will see the following:

Indexing status: "if you're in error it will probably say something other than IDLE"
Items in index: "# of items"
Errors in log: "# of errors"
Content sources: "Local Office SharePoint Server sites"
Crawl rules: "will be different depending on what you've defined"
Default content access account: "Should be a Domain account
Managed properties: Default is 130 defined properties
Search alerts status: "Alert status"
Propagation status: Idle

3) Click on on "Manage Crawl Rules"
Note: You should have the URL of your Site configured here.
4) Click on the URL of the site with the issue(s).
5) Select "Include all items in this path" and check Crawl complex URLs (URLs that contain a question mark (?)).
6) Then select "Specify a different content access account"
7) Enter in the Search User account and password.
8) Use the Breadcrumb and select "Search Settings".
9) Click on "Content Sources and Crawl Schedules".
10) Select your content source ("Local Office SharePoint Server Sites" is the default).
11) Make sure that the URL for your SharePoint site is listed in the "Type Start Address Below" box.
12) Under Crawl Settings, select "Crawl everything under the hostname for each start address".
13) Then set your crawl schedules. Usually you do a Full Crawl outside of your business day and hourly for your incremental crawls.
14) Check the box for "Start Full Crawl"

You can monitory the status of the crawl at the "Search Settings" page. Depending on how much content you have, will determine how long it will take to index. Also it will go through and delete old indexes for deleted content at the sametime. This will add time for the full crawl to complete.

Checking in Files / Removing Locks in TFS

2008-09-24T11:44:00.000-04:00

I've found this to be an issue on multiple occasions. Essentially you're using Team Foundation Server with Visual Studio and a member of your team leaves with code checked out or locked.

There are a couple of ways to fix this but the easiest I've found is with TF.exe. If you have Visual Studio installed and priviledges you can use this tool to fix you problem.

Note: You can find the TF.exe tool in:

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\TF.exe (VS2005)

or

C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe (VS2008)

Get a list of workspaces for a user:

tf workspaces /owner:UserName /server:ServerName

eg. if my user name was JDoe and my TFS web server name MyTFS then the command would be:

tf workspaces /owner:JDoe /server:MyTFS

Note: Use the Host Name of the server you're attaching to. If you have a multiple server configuration, you need to use the Server Name of the web server where your TFS client connects to. Don't use the host header (if applicable) or the http address and you don't need to use the Fully Qualified Domain Name (FQDN).

To remove a workspace for a user, you need to know the workspace and the username. The default workspace name is their development machine name. Occassionally developers have multiple machines, maybe a laptop and a desktop for development. It's not uncommon to have multiple workspaces associated to the same usere.

Delete a workspace for user:

tf workspace /delete /server:ServerName "workspace";"workspaceusername"

eg. if my username was JDoe and my workspace was JDoe2003, and my TFS web server was MyTFS, the command would be:

tf workspace /delete server:MyTFS JDoe2003;JDoe

Get a list of directories in a workspace for a user and display the GUI (Graphical User Interface):

tf workspace "workspacename";"workspaceusername" /server:ServerName

eg. if my user name was JDoe and my TFS web server name MyTFS then the command would be:

tf workspace JDoe2003;JDoe /server:MyTFS

Publishing InfoPath Forms - Updating Content Type Failed

2008-09-10T15:16:00.003-04:00

Scenario: You've published and InfoPath form to a Sharepoint Form Library. You edit the template, save and attempt to publish again and receive the following message - "Updating Content Type Failed"

I've done some researching on this and found a couple of issues. The most common response is that if you remove some columns for your InfoPath List, it will magically work. What I've discovered for this ready why this actually works is because you're falling within the Timeout window. What you're actually doing by removing columns is shrinking the Infopath form from being too large and the web service that is uploading the template is completing inside of 30 seconds.

I don't have a solution for this issue yet, but I am actively working on it. InfoPath is used to capture information and my work around is to reduce the information displayed. That's not accept for me or my business.

I'll post more when I something more concrete. I'm actively exploring optimizing the Infopath form, column types and even increasing the web service timeout to larger than 30 seconds.

UPDATE:

I've found some other work arounds to help with this situation. If you create a new form library, you should not have any issue publishing the form for the first time. You will be able to add all of your columns and publish the complete form. I suspect there is something corrupt with the form library which is causing Infopath to have issues. I'm not sure if it's SharePoint Designer related but I haven't ruled it out.

Separately I've found that most form libraries with issues on publishing form templates, all seem to have multiple files in the library and many different files that are unlinked from the current template. I haven't tested if linking all the files back to the current form template will resolve the issue or not, but it was something I noticed when recreating the form library.

UPDATE #2:

I've done some more investigating and found something interesting. There's not a "hard limit" to the number of columns in a List, but more a limit to the number column types you can have in a list. The interesting part is that there is technically a hard limit on the number of columns and once that limit is reached, MOSS on the back end will create a new row with the same cap. The end user will still continue to see a single giant list.

Here's the breakdown of what you can have in a list can have:
64 Single line of text and Choice (drop-down menu or radio buttons)
31 Multiple lines of text and/or Choice (check boxes (allow multiple sections))
32 Number and currency
32 Hyperlink
16 Date and time
16 Lookup 16 Yes/No
8 Calculated

Note: The number of shared data types are not 64 Single Line of Text and 64 Choice. It's actually 64 total of a combination of either data type.

So we now have a new question:

Does your InfoPath form has more than 199 columns, or has your InfoPath form surpassed the column type limit?

Method 'Publish' of object "ListObject failed.

2008-07-08T14:04:00.000-04:00

I've been trying to import CSV's into a SharePoint Lists. All but one seems to be import successfully. A single CSV is giving me a lot of problems and I only get the very generic error -

Method 'Publish' of object "ListObject" failed.

My work around for this error was to attempt to Create a Custom List by selecting Import Spreadsheet. I gave the list a name, and browsed to my problematic CSV location. I selected my problematic CSV and picked the Range of Cells, and then hit Import.

The looks like it is starting and then failed with the wonderful error message "Method 'Publish' of object "ListObject failed". But it didn't truly fail. It actually will create a list with columns but no records. I navigate to my new empty list and change to Datasheet View. Do a comparision to make sure all of the column headers are correct. Also check to see if your data types are correct for each columns (single line of text, date and time, etc.). Make any adjustments as necessary.

After you're finished jump back to the CSV and select all of the data, minus the column headers (which already exist in the list), copy and paste the data into the First Cell in the First New Column that was created by the failed import. Trying to paste directly into the "Title" Column will cause completely separate issues.

Depending on the number of records you're trying to paste, this may take a few minutes. I've found pasting more than 2000 records with a list over 200 columns is pretty slow. It's also against best practice to even have a list over 2000 items, so make sure you plan accordingly.

Separately, if you have to have all of your items in a single list, which is usually dictated by your customer or your business team, keep an eye on your memory usage on your desktop/laptop you're doing your work from. The more items you copy to your clipboard and then attempt to paste into a list will drive your Internet Explorer Memory through the roof. I've had iexplorer.exe over 1.5GB on multiple occassions. Not something I'd recommend if you're working from a Laptop with 2GB of memory. Less records copied means less memory consumed by IE, but will increase your time spent copying and pasting.

This process only directly impacts your machine. I've confirmed that my desktop is practically unusable while pasting 20,000 records and no one else in SharePoint is impacted. Who says client side processing is bad?

If you don't like the status bar at the bottom of your browser when you're pasting, attempt to navigate away from the list. You'll be prompted to nagivate away and lose your changes or wait. Wait for the changes to complete and you'll get a status bar box in the middle of your window that gives a better indication of your progress.

Rinse, lather and repeat as necessary.

My impression is that Excel was using the SharePoint Web Services to upload the CSV and create a list. Something is breaking after the list is created, and the columns have been created. I don't the exact reason yet, but I'm working on that. When I have an explanation for the error, I'll update the post.

To help protect your security, Internet Explorer has blocked this Website from displaying....

2008-06-30T15:36:00.000-04:00

Unfortunately if you're seeing this message you either have 1 of 2 problems. Either you're visiting a site with an incorrect SSL Cert or your visiting a site with an expired SSL Cert.

If it's an expired SSL Cert, then the obvious fix is to renew the cert and install it. If the Cert is still valid but not cofigured correctly, IE7 now will do you a favor and block the content.

The main issues with incorrectly configured SSL certificates seems to be the "Issued to" field. It should be read the URL of the site, rather than the contact information. IE6 didn't care about this field but IE7 takes it very seriously.