In the past (in the days that sharepoint still was called MOSS ) we often used port 10000 for central administration. Until we installed it at a customer who had BackupExec as their backup solution.

Seems that the BackupExec agent uses port 10000 to communicate with the BackupExec server. This forced us to review our Central Admin port strategy. Instead of simply using a convenient port number, we decided to research what would be a good port number.

We asked our customer which ports the all used, and we finally decided on a new port number for CA.

When SharePoint 2010 arrived we kept using our chosen port number.

Today, a customer told me that they could no longer backup their server on which SharePoint was installed.
They were using: Backup Exec

So my first guess was, backup exec changed the portnumber of their agent. But this wasn’t the case.

After some investigation it seems that BackupExec 12.5 agent stops working when SharePoint 2010 is installed.

The 12.5 version doesn’t support SharePoint 2010, but in this case was also not needed. We simply wanted to backup files fro the file system.
The SharePoint agent was not to be used.

But the backup exec agent thinks otherwise. It has 2 SharePoint dll’s on board and it really want to see if it can connect to SharePoint.

even when the dll’s are build for older version of sharepoint, it will try to make a connection. And that’s the issue. It simply cannot connect but the process hangs itself trying to connect.

The solution:

1. Stop the backupexec service on the sharepoint server
2. goto to the RAWS directory
3. rename the sharepoint dll’s (bedssps2.dll, bedssps3.dll) so the no longer function as dll (add .old)
4. restart the backup exex service

Your backup exec server should be able to connect to the sharepoint server again.

Symantec has a support page on this issue:http://www.symantec.com/business/support/index?page=content&id=TECH125045

I have a SharePoint 2007 enviroment (Dutch) with Project server (Dutch) installed.

I created a custom search scope. I added this scope to the dropdown list on my portal. When i use this dropdownlist, i can see the new scope.

I also wanted this functionality on my Project Web Access site(collection). Actually, i even want that new scope to be the default scope.

So i added this scope….. but it didn’t show up (i redirected to search center)

After some investigation. i saw that everything was dutch EXCEPT the names of the display groups.

Although all functionality and all buttons and everything else, it struck me that the names of the different groups where not translated.

I went to my primary portal, retrieved the name of the displaygroups, as they are named in dutch.

Created a new group in my PWA site, added the scopes i want, and guess what : My pulldown menu from the search box, was correctly filled wit hthe scopes i entered.

Seems Microsoft made a hickup in translating

Regards,

Eric

Als je in een nederlandse SharePoint2010 omgeving gebruik wil maken van de filter [Me], waarbij je dus een lijst kunt filteren op basis van de naam van de persoon die is ingelogd, dan staat er bij het filter netjes, dat in een Nederlandse omgeving hier [Ik] gebruikt moet worden.

Echter, het zal je opvallen dat dit niet werkt.

Vervang echter [Ik] door [Mij] om de filter wel werkend te krijgen.

De omschrijving klopt niet met de werkelijkheid.

Packages Impacted

The Cumulative Update packages affected are the Server Packages for SharePoint Foundation, SharePoint Server and Project Server 2010, specifically; 

1. SharePoint Server Package 2394320
2. Project Server Package 2394322

go here for more information

Ever seen this message.

It seems that when you have Office 2010 64bit isntalled, or no office at all, this message is generated by SharePoint when trying to open a list in Datasheetview.

The reason is that it depends on functionality that is part of office 32bit.

So , how can we fix it. According to Microsoft there are 2 methods. Take  a look at this page to see which methods.

I think there is only one (is also mentioned on the MS support page). Install the 2007 Office System Driver: Data Connectivity.

After installing everything is working as intendend.

regards,
Eric

If you installed Microsoft SharePoint Server 2010 For Internet Sites Enterprise, and then you tried to activate the product by using the enterprise key before May 25, 2010, you encounter the following symptoms:

• The following Enterprise features are not available, or the features have reduced functionality:
  • Access Services
  • InfoPath Forms Services
  • Chart Web Parts
  • Excel Services
  • PerformancePoint Services
  • Visio Services

To verify that you are encountering this issue, consider the following scenarios:

• One of the following GUIDs exists in the output of the (Get-SPFarm).Products cmdlet:
  • 1F230F82-E3BA-4053-9B6D-E8F061A933FC
  • F48AC5F3-0E33-44D8-A6A9-A629355F3F0C
• The following registry subkey contains one of the previous GUIDs:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\WSS\InstalledProducts\{90140000-110D-0000-1000-0000000FF1CE}

For more info and a solution look here : http://support.microsoft.com/kb/2143810

As every developer should know m the SPSite and SPWeb objects have problem resulting in memory leaks. On the background they call “unmanaged code”. so when using SPSite objects or SPWeb objects in your code, always use ways to dispose these object (think of try-catch and using).

there is even a tool to check if you really dispose all the necessary object (link)

But today i saw an article that told me there is another memory leak problem.

Look at this article of Todd Carter to see more of it, he call’s it : SharePoint’s Sasquatch Memory Leak

I had a problem writing to the eventlog.

I got a message telling me i don’t have write access. I couldn’t believe that, since under normal circumstances everyone could write to the application log. At least, that’s how it should be.

Searching the internet i found this blog.

bottomline: use elevated permission for writing to the application log
Eric

In one of the teams i’m working, we had an issue with double-hop.

When using NTLM and several servers need to be connected, this could be an issue.
Example: when you use 2 web front ends in combination with forms, everything is allright.
But, when the form uses webservices for collecting information, you could run into the double-hop problem.

Standard: NTLM will only authenticated between 2 computers, any extra computer will nog be authenticated to.

Within Sharepoint you can overcome this issue by implementing Kerberos or Single Sign ON.

Due to the nature of kerberos (delegation of control), we decided to go for Single Sign ON.

At this moment, single sign on works every now and then, but never without faults and never longer then 4 hours.
The configuration was cleared every 24 hours (!?)
During examining the logs and application log, a weird error caught our attention.
Some more investigating learned that these errors where created during single sign on configuration.

The error was related to localhost in combination with Alternate Access Mapping.

How is this possible ?

The name of out server was (fake name) : mossapp
we created AAM config lines pointing to mossapp. Everything is working as intended (including central administration)

All sites go to the right host(header).
But single sign on complains about not finding Localhost.

So we added localhost to the AAM pointing to mossapp.

And guess what : the errors where gone !

At this moment the configuration is no longer cleared, but unfortunately, single sign on is still not working as intended.
although, if it’s working, it works for at least 8 hours.

Anyone ideas about this issue ?

eric

I installed my virtual server (clean install) to do some testing with the Groupboard workspace. Heard that it would be a nice feature to use.
I installed Sharepoint in a FARM setup , and upgraded to : SP1 + infrastructure upgrades (version : 12.0.0.6318)

I created all things for a server farm (if all is well the red alert will disappear in central administration ).
I create a sitecollection with team portal as root site.

I then installed the Groupboard Workspace. So far so good.
I started with creating a new site based on this site-template > i got an error, saying something about the default.master.
So i opened the site settings (this was working) and when going to the masterpage section , i saw 2 warnings. I changed the masterpage (warnings where gone) but still no access to the site.

I went to Central administration to see if there was something with the solution, but then my eye caught something strange: The warning that the farm was not complete had returned.

HUH ! How is that possible.

After doing some checking i found out that one service stopped : Windows SharePoint Services Help Search.
So i decided to start it again….. unfortunately this ended in an error : The specified SPContentDatabase Name=SharePoint_AdminContent_f96e1b00-82e8-45ab-90de-8bbc56eb3c84 Parent=SPDatabaseServiceInstance has been upgraded to a newer version of SharePoint.

Huh again …. how is this possible.

I’m still not sure what is causing the problem, but after uninstalling the Groupboard workspace, the service started without any errors, and my site was working againg.

Hope this will help others with pinpointing this problem.
Will do some investigating later.

Eric