Environment
- Windows 2008 R2, Windows 2008
Issue
On Windows 2008 R2, when one
- Navigates to Component Services > Computers > My Computer > DCOM Config > IIS WAMREG Admin Service
- Click on Properties (for IIS WAMREG Admin Service) and navigate to the Security tab
- Edit Launch and Activate Permissions is disabled
Resolution
After raking my brain on this issue (and searching) I finally came across the cause and resolution here
http://www.wictorwilen.se/Post/Fix-the-SharePoint-DCOM-10016-error-on-Windows-Server-2008-R2.aspx
I am documenting this so others do not have to spend hours trying to resolve (and search) this issue and some of you can get to this issue faster using correct keywords (hopefully)
Environment
- SQL backend, SSRS server: SQL 2008 SP1
- SQL backend is behind the firewall with only specific DB port open (port used by SQL browser is not open…hence the need to specify specific port)
- RS service login has DB Creator and Security Admin privileges
Issue
During initial configuring SSRS (in creating RS database) we kept getting (during 'generating Rights script' step)
System.Net.Sockets.SocketException: No such host is known
at System.Net.Dns.GetAddrInfo(String name)
at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
at System.Net.Dns.GetHostEntry(String hostNameOrAddress)
at ReportServicesConfigUI.RSDatabase.IsLocalDbServer(String dbServer)
at ReportServicesConfigUI.RSDatabase.GrantRSConnectionRights()
at ReportServicesConfigUI.RSDatabase.CreateNewDatabase()
RS database does get created but is in incomplete state.
Per http://blogs.msdn.com/psssql/archive/2009/03/05/socketexception-when-creating-a-new-report-server-database.aspx specifying port will not work.
This has been verified (that it does not work) by using SQL alias (which references port) as well as specifying it within "server name,port\SQL Instance" name format (for e.g. SQL_Server,1234\SQL_Instance…port used by SQL instance is 1234)
Using without port references works (for e.g. SQL_Server\SQL_Instance format)…but for this to work,SQL Browser service needs to be enabled and UDP 1434 port needs to be opened through the firewall (if one exists)
Using format SQL_Server\SQL_Instance format works as long as SQL Browser service is running and in case of firewall the SQL Browser port is open (which is not always the case)
Btw, little more digging we did find a workaround….
It seems if you use a connection format like “ServerName\InstanceName,Port”, then SSRS Configuration manager is able to connect without requiring the SQL Browser service.
Without SQL Browser service running (either shutdown or blocked behind the firewall), SSRS Configuration Manager still does not work with “ServerName,Port\InstanceName” format or via SQL Aliases.
Technologies involved
Performance Point Server 2007
Performance Point Server 2007 SP2
SQL Server 2008
Environment
Performance Point Server 2007
Issue
After installing monitoring server on a server (without issues and all pre-requisites installed) and running Dashboard design etc, while connecting to performance point server for managing permissions(using Options), kept getting "Unable to connect to server" message.
Within the events log on the server, listed below events were logged.
Event code: 3008
Event message: A configuration error has occurred.
Event time: 6/2/2009 11:13:49 AM
Event time (UTC): 6/2/2009 5:13:49 PM
Event ID: 1bde680dd7bd42ff9441ff6423ac8fcd
Event sequence: 1
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/986432534/Root/WebService-4-128884364298709719
Trust level: Full
Application Virtual Path: /WebService
Application Path: D:\Program Files\Microsoft Office PerformancePoint Server\3.0\Monitoring\PPSMonitoring_1\WebService\
Machine name: PerfPointServer
Process information:
Process ID: 3412
Process name: w3wp.exe
Account name: domain\lsvc-perfpoint
Exception information:
Exception type: HttpException
Exception message: Could not load file or assembly 'System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. (D:\Program Files\Microsoft Office PerformancePoint Server\3.0\Monitoring\PPSMonitoring_1\WebService\web.config line 25)
Request information:
Request URL: http://Server:40000/WebService/PmService.asmx
Request path: /WebService/PmService.asmx
User host address: 10.237.214.235
User:
Is authenticated: False
Authentication Type:
Thread account name: Domain\lsvc-perfpoint
Thread information:
Thread ID: 1
Thread account name: Domain\lsvc-perfpoint
Is impersonating: False
Stack trace: at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()
at System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled()
at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters)
Custom event details:
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Analysis
The issue was related to reference to System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 which was missing in the GAC. System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 was present, but the version 1.0.61025.0 was missing.
This was true even thought within the configuration of monitoring server it explicitly stated that ASP.NET 2.0 AJAX 1.0 was installed.
Resolution
This issue was resolved by installing ASP.NET 2.0 AJAX 1.0, which in turn installed the missing System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 in the GAC.
Note: Within the configuration of monitoring server it explicitly stated that ASP.NET 2.0 AJAX 1.0 was installed originally.
Technologies involved
Microsoft Office SharePoint Server 2007
SQL Server 2008
Environment
-
WFE (Query)
-
IJS (Index)
-
SQL Server
Issue
Out of nowhere, we found that indexes were not getting propagated to our Query server.
Within ULS logs, we would see messages like "Query Server(s) not ready".
Within Central Admin, we would see messages like "Waiting on Initialization (XXX) (on Search Admin screen) and "Propagating to Query Server" (on Search Status screen).
Search propagation would be stuck in this state for ever.
No amount of restarting or recreating SSP would solve the issue.
Resolution
Turns out that “Windows SharePoint Administration Service” was not started on Query server. Once re-started indexes started getting propagated to the Query server.
Technologies involved
Project Server 2007 (SP1, Infrastructure Update)
Portfolio Server 2007
MOSS(SP1, Infrastructure Update)
Issues
Kept getting "Authentication data undefined for specified Project Server and current user" message when trying to Synchronize Resource Pools within Portfolio Server 2007
Resolution
This is usually due to listed below 3 causes
|
Potential Cause |
Resolution |
|
User attempting to use the gateway has not set Preferences on their client machine |
- Log into Portfolio Server
- Under “Builder”, click “Preferences”.
- Click “Project Server” under “Microsoft Project Preferences”.
- Click to choose the proper Server Name, and click “Edit”.
- Perform the proper changes, and click “Update”. (If Windows Integrated Authentication is used, do not need to change anything.)
|
|
The Shared Service Provider has not been configured to share between farms (if Project Server and Portfolio Server are on different machines) |
1.Configure SharePoint to allow the gateway to work correctly
- Launch the SharePoint Central Administration site on your Project Server machine and click on Shared Services Administration
- Click to the right of the SSP name and select Edit Properties
Note: If you have more than 1 SSP, make sure you select the SSP that is hosting your Project Server site (should be the same SSP name as what was defined in the Web Service URL)
- In the Edit Shared Serviced Provider page, scroll to the bottom of the page to the section: Process Accounts with access to this SSP and specify a windows account that has administrative access to both Project Server as well as SharePoint. E.g. domain\username.
- Determine the Identity for the Application Pool that the web site for Portfolio server is using. If it is the Network Service then grant access to the "NT AUTHORITY\network service" for the Shared Service.
- Click the Check Names icon to ensure that the account specified is valid and click OK
- Next click on the Application Management tab and select Grant or configure shared services between farms
- Select the option, “This farm will provide shared services to other farms”
- In the Provide Shared Services section, specify the machine account in the form of Domain\MachineName$
- Tip: If PPS, SharePoint and ProjectServer are all installed on a single server and is in a workgroup environment, specify the network service account in the form of: "NT AUTHORITY\network service"
- Click the Check Names icon and verify that the name is valid and click OK.
- On your client machine close out all the IE windows and on the server where PPS 2007 is installed, click on Start | Run and type IISReset
|
|
Ensure URLs configured for the gateway is correct |
- Check for the correct Project Server Web Service URL. It should look something like this:
http://<Central_Admin_machine>:<port>/<Shared_Services_name>
The port you have to specify here is by default: 56737, but if you changed the PSVR install, you can find it following these steps:
1. Start IIS manager
2. expand Web Sites
3. right click on Office Server Web Services - select Properties
4. look in TCP port. You will use this in the link mentioned above.
The Shared Services Provider name will be the one you can see it under Office Server Web Services and the one that hosts the PSI folder
- Check the PWA URL - Note: for integrated or forms PS authentication.(http://<PS machine name>[:<port number>]/<PWA Instance>). To check make sure you can browse to the URL used for PWA.
|
Technologies involved
Project Server 2007 (SP1, Infrastructure Update)
SQL Server 2005 SP2
Issue
When trying to build an OLAP cube, we kept getting "Your permissions on the server computer do not allow you to administer this analysis server".
In our environment, we wanted to configure Analysis Services to use SQL DB, not Jet database.
After ensuring the security permissions and related steps (http://technet.microsoft.com/en-us/library/cc197489.aspx), we still kept getting this issue.
Turns out that the error message "Your permissions on the server computer do not allow you to administer this analysis server" is a catch all message and the final resolution turns out to be a poorly documented step.
Resolution
It is very important to ensure that all security settings have been applied as documented within http://technet.microsoft.com/en-us/library/cc197489.aspx (especially verifying that ssp service login can access the Analysis services)
If you still keep getting this message, the most likely cause is the missing additional steps listed below.
Note: This is just valid for Analysis services repository residing in SQL database (not Jet database)
- Follow the steps listed below (copied from http://technet.microsoft.com/en-us/library/cc197552.aspx)
Create a shared folder for the repository
You must create a shared folder in SQL Server 2005 Analysis Services where the repository will be located. You also must make the shared folder accessible to accounts that will need to access it.
Create the shared folder
1. In Windows Explorer, browse to the folder containing the Analysis Services installation. By default, it is located at: C:\Program Files\Microsoft SQL Server\MSSQL.X\OLAP
2. In this folder, create a new folder and name it DSO9.
Note
If the subfolder MSSQL.2\OLAP does not exist, use the \OLAP folder in one of the MSSQL.X subdirectories.
3. Right-click the DSO9 folder, and choose Sharing and Security.
4. On the Sharing and Security page, in the Sharing tab, select Share this folder. In the Share Name box, type MSOLAPRepository$ as the share name for the folder.
5. In the Security tab, in the Group or user names list, select SQLServer2005MSOLAPUser$SERVERNAME$MSSQLSERVER. Select the Allow check box next to the Full Control item in the Permissions list, and then click OK.
6. Click Add. On the Select Users, Computers, or Group page add the account running the Project Server Queue service on the Project Server application server. Click OK.
Note
To verify this account, on the Project Server application server, click the Start menu, click Programs, click Administrative Tools, and then click Services. Double-click Microsoft Office Project Server Queue Service and note the account on the Log On tab.
7. In the New Folder Properties page, click OK.
- For MSOLAPRepository$ share, please ensure that SSP service login also has full control over the share
- Within In addition to DSO\RemoteRepositoryConnectionString as well as DSO\RepositoryConnectionString (Configure Analysis Services to use a SQL Server repository database Pasted from <http://technet.microsoft.com/en-us/library/cc197552.aspx> ) also fill in values DSO\RemoteLockDirectory (for e.g. set it to "\\AS_Server_Name\MSOLAPRepository$") and DSO\LocksDirectory (for e.g. set it to "C:\Program Files\Microsoft SQL Server\MSSQL.X\OLAP\DSO9)
Hopefully after performing the above 3 steps, you should be able to build the cube.
Issue
User get’s a listed below error when opening a new or existing InfoPath form because of an error in the form's code
Error
“The required version of the Microsoft .NET Framework is not installed on your computer or the InfoPath Primary Interop Assembly (PIA) is not registered. Use Add or Remove Programs in Control Panel to make sure that the required version of the Microsoft .NET Framework is installed. Or install it using Windows Update and run the Setup program again to confirm that the corresponding version of the .NET Programmability Support is installed, or contact your system administrator.”
Cause\Resolution
As the error message suggests either the Microsoft .NET Framework or the InfoPath Primary Interop Assembly (PIA) is not installed. If Microsoft .NET framework is not present on the system then this will need to be installed. If the user does not have the .NET Framework already installed (when installing Office 2007) then PIAs will not be installed. Additionally, the option to install the PIAs doesn't show up in the Custom setup for Office. If the user does a complete install of Office 2007, then PIAs will get installed into the GAC automatically. It's strongly recommended that a complete install of Office 2007 be performed.
If .Net Framework is installed after installing Office 2007, then PIA does not get installed automatically and this can to be installed by following the steps listed below
1. Go to 'Add or Remove Programs...'
2. Select the Microsoft Office 2007 installation and click on change.
3. Select “Add or remove features” and click Continue.
4. Expand the “Microsoft Office InfoPath” and “.NET Programmability Support” node. Add the '.NET programmability support’. To add, right click on the node and select “Run from my computer”. Press continue and follow the on screen instructions to complete the setup.
As with any production environment, the next exercise (after configuring SSRS in SharePoint Integrated mode using NTLM) was to get it configured using Kerberos.
Listed below are the steps required to accomplish SSRS configured for SharePoint integration mode to use Kerberos authentication.
Note: These instructions are specific to enabling Kerberos for SSRS integration only. It is assumed that Kerberos is already enabled for SharePoint farm. Also it is assumed that SSRS has SharePoint installed configured as a WFE. On exact steps to configuring Reporting Services for SharePoint integration please review http://technet.microsoft.com/en-us/library/bb326356.aspx link.
Server Farm Configuration used
- 2 WFE
- SSRS server
- Index server
- SQL Server Cluster
Listed below are the steps taken to accomplished enabling SSRS for Kerberos authentication.
- Create the listed below SPN
setspn.exe –A HTTP/FQDN_of_SSRS_Server domain\RS_Service_Login
setspn.exe –A HTTP/NetBios_Name_of_SSRS_Server domain\RS_Service_Login
- Enable Trust for Delegation
In addition to setting the SPNs for each of your service accounts, you also need to trust each of the computer accounts and some of the service accounts for delegation. Trusting for delegation means that the accounts are allowed to delegate on a user's behalf.
In order to trust for delegation you need to open Active Directory Users and Computers as a user with domain administration rights and follow these instructions
- Repeat for each of the following
- FQDN_of_SSRS_Server
- SSRS Application Pool: domain\RS_Service_Login
- Locate the account and click 'properties'
- Navigate to the 'Delegation' tab
- Choose 'Trust this user/computer for delegation to any service (Kerberos)'
- Within Central Admin, ensure that the SharePoint Central Administration site is set to use Kerberos authentication
- Ensure client browser is set for integrated windows authentication (http://technet.microsoft.com/en-us/library/cc779070.aspx)
- Ensure that on SSRS server the web site used for SSRS is set to enable to use Kerberos authentication. This can be verified using adsutil.vbs script. Note: For SSRS 2008, extra steps need to be performed as noted in http://msdn.microsoft.com/en-us/library/cc281253.aspx
- Within Central Admin, "Reporting Services" section, click on "Manage integration settings" and enter appropriate URL. Please ensure "Authentication Mode" is set to "Windows Authentication"
- Click on "Grant database access", enter appropriate information and click ok
- Click on "Set server defaults". This is the test. If everything is configured properly, then you will be taken to the next screen. If configuration is incorrect, you may encounter "Verify that the report server is available and configured for SharePoint integrated mode". If this is the case, go back and ensure all the steps listed above are executed correctly.
Note: once you implement Kerberos everyone looking at the reports has to be on the same or trusted domain'ed machine and no one will be able to switch users using the log in as function and still view reports. If this is the case then SSRS will give 401 in both cases.
For getting SSRS to work in NTLM, review below blog post on how to avoid using Kerberos with a multi machine setup of ssrs http://blogs.msdn.com/feldman/archive/2007/11/18/quick-guide-on-how-to-install-reporting-services-on-its-own-server-cluster-in-sharepoint-integration-mode-without-using-kerberos.aspx
Client kept getting “The target location you specified is not supported by the report server” message every time they try to run a SQL 2005 report manually deployed to SharePoint document library (MOSS). This same error also showed up when we go to “Set Server Defaults” (in the top section) page in Central Admin .
This same report worked fine when a subscription is enabled and the subscription runs in un-attended mode.
Within “Manage Integrated settings” page, the authentication mode is set to “trusted account” as Kerberos is not enabled.
The cause for this message was because there was another Alternate Access Mapping (AAM) set up for Central Admin.
Once the extra AAM was removed, the error disappeared and issue was resolved.
Here is the link that helped resolve this issue http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2991956&SiteID=1
Per Shawn Feldman (a colleague of mine), the reason for this is due to Reporting Services in SharePoint Integration mode does not support multiple zones. That’s why it errors out when one has a second AAM.
We have encountered issues related to email enabled document libraries stop receiving emails.
After investigations listed below is the synopsis of the issue.
Background
- Intermitently we have encountered (on different environments) issues with email enabled libraries stop receiving emails
- Emails enabled document library successfully received emails for months
- Suddenly document library stops getting emails
- Within the configuration of the doc lib, we see that the doc lib is still email enabled, but it would not received emails
- Within the ULS log there is a message “The following aliases were unknown: XXXX” as SharePoint cannot verify\locate the email alias
Result
- Emailed enabled document library stop receiving emails
- As SharePoint does not send back notifications for emails it could not process, sender is unaware that the emails did not reach its destination in SharePoint
- Within document settings, the document library still shows as email enabled
Cause
- A triggering event (at present this is unknown as we cannot recreate it in dev\test) causes email alias to be marked as deleted within MOSS_CONFIG.EmailEnabledList table
Fix
- Disable and enable again the email setting within the document library
- Run “stsadm –o refreshdms –url <web application url>”. Note: This command will re-sync and enable all email enabled document library present within a specific web application.
Workaround
- Until we are able to identify the triggering event, we are
- Proactively monitoring the MOSS_CONFIG.EmailEnabledList table to check for any email enabled list with Deleted column = true. This is an indicator that email enabled document library may not be receiving emails.
- If we encounter such a scenario, then we run “stsadm –o refreshdms –url <web application url>” noted in the Fix section above or reset the email enabled setting
Currently looking into the triggering event, hence if we find one, I will post it.
