I have a sharepoint farm that has 2 WFE+1 APP +1 SQL server architecture. I have deployed a solution package which contains webparts and a few things related to site level.
It warns me that the setup files, webparts are missing in the central administration even though the solution packages are deployed the web application. BTW, there is a web application on the farm.
I have checked the below articles. But in those articles offers the deploy the solutions for whole web applications on the farm. Furthermore, one of those articles is related to search webpart and the another of them is related to default webpart in the admin_ content db. But my issue is related to custom solution files that is in the wss_content db.
https://blogs.technet.microsoft.com/christianheim/2016/09/15/missing-server-side-dependencies-errors-on-your-multi-server-sharepoint-farm/
https://sharepointsoldiers.wordpress.com/2013/04/22/sharepoint-2013missing-serverside-dependencies/
Related
Iam trying to develop webpart for firm website on SharePoint with visual studio, the problem is that there is no solution for SharePoint online - Visual web part. When i try to create SharePoint 2013 - visual web part, I get an
error message.
The only thing there is for Sharepoint online is Apps for Sharepoint and that isn't a web part, or atleast I haven't found a way to use it as such.
When I talk to my supervisor about the error, he tells me that they can't create a virtual server for me to install the SharePoint server on and I have to code it through the Sharepoint online.
Is there any way for me to develop and deploy the webpart with an online Sharepoint server instead of local one or to atleast create it through the apps for Sharepoint?
You can use App Parts, those are Web Parts that display content from an installed App, you can add them at any page of your site as normal Web Parts, App Parts are deployed in the same package as your App, so you can have everything in the same solution.
There are plenty of resources that will help you to develop Apps and to include App Parts also, just look for the right concept in google and you will find it.
There are two kinds of SharePoint Apps (or Add-ins which is the new name), the first one is SharePoint Hosted App and the second one is SharePoint Provider Hosted App, the one you need will depend on the functionality you want to achieve, but as a general reference you can think on the data source that you want to consume in your solution, e.g. if the data to be used by the App is in the SP Site where you are going to install it, then all you need is a SharePoint Hosted App, however if the data is in an external location like databases stored in local servers, then you will need SharePoint Provider Hosted App. Of course this is just a very basic view of this topic, there are other reasons to use one or the other but its pointless to make a full list here. This is a wide topic and you can find tons of articles and guides about this.
If all you need is a simple webpart to display some content with a nice look or roll up some content and provide an output based on it, then you can use a SharePoint Hosted App, which is the easiest to develop and deploy, with this kind of app you can use JavaScript get the data from your site, and then you can display your output in an App Part.
I'm sorry to not provide specific pages to read, but that's just because it's better to look for the guides that be easier for you to understand and that may vary from person to person, all you need to know is the concepts and topics to search for.
If you want me to help you with this please send me a message (my profile).
I have a custom webpart for Sharepoint 2007. I am trying to deploy it to a new Sharepoint web application. I am using WSPBuilder with VS2010 to do the deploy. When I examine the wss\VirtualDirectories\ folder for the web app, the wpcatalog folder does not exist there. When I go to the Web Part Gallery and click "New" button, the web part is no there either. What could be causing this behavior? Are there any other ways to troubleshoot it?
Thanks.
the wpcatalog is actually a document library containing the .webpart definition files. It is stored in the content database, not the file system.
You need to verify the solution is in fact deployed to your web application, and then activate any features if necessary. You can verify the solution deployment under central administration\operations\solution management.
I want to perform the data migration between two SharePoint farms located on the same active directory. I don't know on how to migrate the data from one SharePoint from to another new SharePoint Farm
Several ways of doing this:
1) Backup content database on source farm and restore in target farm, then attach to a web application.
2) Create (i.e. export) a content migration package on the source farm and import on the target farm
3) Set up a content deployment path between the source and target farms (probably not appropriate in this case)
All of these are documented extensively on Technet. If you have custom or third-party code you will need to deploy these to the target server also.
The fundamental processes will be like this:
Create a new web application in your new WSS server.
Follow the instructions in Move content databases between instances of SQL Server.
However you may not be able to perform all of the steps exactly as written if your previous server farm is not available. The main thing is that you get the most recent backup of the databases restored on your SQL Server, then follow these steps from the linked article:
In Central Administration, on the Application Management page, in the SharePoint Web Application Management section, click Content databases.
On the Manage Content Databases page, click Add a content database.
On the Add Content Database page, type the exact name of the transferred content database, and then click OK.
Repeat steps 14 and 15 for each database you are adding. Be sure that you select the correct Web application from the Web Application menu for each database.
I don't know your farm topology but if you are sharing the same SQL Server used for the dead server farm, make sure that the dead farm is completely powered off. You don't want two different SharePoint farms accessing the same data (especially if one is in an inconsistent state).
If the old farm is alive and not in inconsistent state then you will be better off using a migration tool even if the versions of new and old are same.
The reason is that service packs, patches as well as order of their installation causes differences in SharePoint instances which can mess backup-recovery mechanism.
Migration is much more forgiving as it pre-assumes that differences exist between source and destination.
Several migration tools are available with Sharegate being my favourite.
So, my client wants a customer dashboard integrating all information related to a project in a common sharepoint site.
So we have something like this
http://tdg-srv-006/ <------- Sharepoint site (SP)
http://tdg-srv-006/PWA/ <--- Project Web Access site (PWA)
http://tdg-srv-tfs2/ <------ Team foundation Server (TFS)
He wants the following requirements:
Burn down Chart: this one is located in the TFS server inside the company.
Total count of bugs: this one is located in TFS too
Open Issues and Risks: This one is located in PWA
Team names and roles: this one in TFS.
My question is, how do I communicate Sharepoint with TFS database and with PWA information? any comments, suggestions or clues?
There are two ways to do this. Use the project dashboard site created from Project Server, or the one created by Team Foundation Server.
Project Server
The standard way of setting up such a dashboard with Project Server is to enable project workspaces. This means that when a project is first published it would have a URL such as http://tdg-srv-006/PWA/My%20Project. This is where the project 'dashboard' site will reside, containing both your integration with Project Server and with TFS.
These workspaces are created from templates. They can be extended with your own design and web parts so they will always be created exactly as you'd like. For example, integration with Reporting Services reports that query the Project Server reporting database or Team Foundation Server is a popular idea.
Note that project workspaces already come out of the box with risks and issues. (These can also be linked to tasks and other risks and issues for a richer experience.)
For aggregation, within Project Web Access it is possible to create a view which sums the risks and issues from across all project workspaces and displays them in Project Center. When connecting to PWA, users are also prompted with the risks and issues outstanding that are assigned to them.
Team Foundation Server
Team Foundation Server also creates its own SharePoint site which you may prefer to use. This article on SharePoint Magazine should give you all you need to know. Again, you can set up Reporting Services reports that point to a TFS data source and display the results in your workspace. It just depends on whether you prefer to start with a TFS workspace or a Project Server workspace.
Caution
Both Project Server and TFS only install the free Windows SharePoint Services (WSS) by default. This means functionality such as the content query web part provided in SharePoint 2007 (MOSS) is not there. You can add SharePoint 2007 without any issues but it will cost you more.
The template approach that Project Server uses to create workspaces (and perhaps TFS as well) has problems. Firstly, Project Server will allow you to change columns and fields on the Risks and Issues lists but this will cause errors. There is a safe method outlined in the link earlier on my blog. Secondly, assuming you decide to change the template you will need to programmatically update every workspace within Project Server, including the template to make the changes. Not a big deal but a hassle nonetheless.
Other integration
Finally add the Project Server / Team Foundation Server connector into the mix. This will ensure work item data in TFS is kept in sync with project plan data in Project Server. Note that it has nothing to do with creating a dashboard/workspace.
I know that creating a site template from a MOSS publishing site is not currently supported by Microsoft.
Can anyone tell me if creating a basic site, then turning on the publishing feature, then creating a site template is supported - I would guess not as it's probably the same as creating a publishing portal?
You can staple the publishing feature onto your site template.
From KB 986908:
You can create a stapling feature to staple the Office SharePoint Server Publishing feature to specific site templates. For example, see the Feature.xml file in the "Drive:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\Template\Features\PublishingStapling" folder. To staple the Office SharePoint Server Publishing feature to all site templates, use the TemplateName="GLOBAL" property. This property staples a particular feature to a site definition if the site definition does not specify the AllowGlobalFeatureAssociations property. (Only the Shared Services Provider site template and the Blank Site site template use the AllowGlobalFeatureAssociations="FALSE" property.)
For example, when you use the TemplateName="GLOBAL" property to staple the Office SharePoint Server Publishing feature, a site that is based on the Team site template uses the system master page that is configured for the root site of the site collection.
you can still access the save template webpage, and save it...
for example http://localhost/website/_layouts/savetmpl.aspx
and it works like a charm :-)
I don't think what you're describing will work (like you said, it's basically the same thing as a Publishing Portal), but there appears to be a workaround. According to this post from the SharePoint Solutions Team (apparently not related to Microsoft), you can create a publishing site, customize it as needed, deactivate the publishing feature, create a site template from it, create a new site based on the template, and then activate the publishing feature on your new site.
It sounds like this works, but is not officially supported by Microsoft. Be careful, since it may mostly work, but I wouldn't be surprised if some small pieces of it break.
We wrote our own tooling to solve the export problem. We can create site columns, content types, master pages, page layouts etc in the Publishing site, and export selected items to a WSP package for deployment to other servers.
The tool SPSource takes a similar approach, but creates a Visual Studio solution for compilation. The result can be packaged with WSPBuilder.