I'm building a few WSPs (a custom web part and a branding wsp both scoped to site collection level) using WSP builder on VS2010. Our SharePoint 2007 Farm contains two Web applications.
I'd like to know whether deployment of a WSP to a particular web application (Web App A) will only recycle the application pool for that given web application (Web App A). And that the other web application (Web App B) would be unaffected during this process.
What I want to ensure is users of the other web application won't experience any down time in anyway during this release and that the wsp appears only in one Web App when viewing the site collection features lists.
Does this type of deployment only cause app pool recycling or does IIS get reset too?
Many thanks in advance
The WSP deployment only recycles the app pool containing your site collection, as opposed to an iisreset which resets all app pools.
Users of the other web application will experience down time during this deployment only if the two web applications share the same app pool (unlikely in best practice SharePoint setup).
The WSP will appear only in one site collection features list, the site collection where it was deployed.
WSP Builder is a good tool to use in VS2010 for SharePoint 2007 deployment, the tool is correct in terms of paths and naming and can be trusted!
Visual studio 2010 and wspbuilder 2010 will possibly give you an incorrect structure or naming. Just thinking about the 14 hive and the 12 hive. I might be wrong but worth a check.
However back to your question.
Adding a solution(WSP) to the farm should have any impact on what the users see.
Deploying the solution causes the Application pool of the given web application to recycle. Remember that(i have seen this) some places host many on one application pool meaning you will effectively see anything attached to that application pool suddenly become slow/ unresponsive for a short period of time.
Theoretically as long as Web App A and Web app B are on seperate application pools you should only see one or the other affected ( depending where your deploying)
See http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/thread/385eb454-5083-47a6-b378-615b67a065a3/
Related
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/
After deploying my new Sharepoint solution, containing a feature with WebApplication scope, I noticed that feature was added to ALL webapplications in the farm.
The solution was deployed to a one particluar webapplication, so I wonder if such behavior is correct. Any way to make feature appear only in WebApplication, solution was deployed to?
How did you deploy from powershell or from central admin? If you deployed from central admin you should have been given a list of web apps to deploy too, but if you did powershell and left off the WebApplication flag (http://technet.microsoft.com/en-us/library/ff607534.aspx), it would have deployed to all of the web apps.
This is unfortunately by design.
The solution is deployed to a single web application, e.g.
but the features are visible on all web applications, i.e.:
Feature /= solution. That means that some elements from the solution (not features) will appear only in the designated web application.
One workaround is to hide the feature so that users cannot activate it.
Check out also these posts:
Is it possible to deploy a solution to a web application so that its features are only visible within this web application?
Creating a solution that deploys to selected WebApplications but copies the assembly to GAC
if the solution deployed to ABC webApp so it won't deployed to another WebApp, if it happened better remove from all WebApp and deploy to ABC webApp by PowerShell command.
-
Praveen
I have a single web project that I want deploy in Azure.
I want to create one IIS web site per country and I want to be able to deploy each web site independently (not all of them at a time). How to do this?
Well,
you have two options:
Use Windows Azure WebSites to host your websites
Use Windows Azure Accelerator for WebRoles or your own project similar to that approach.
However you have to note that the second option is a project that is no longer being supported due to avialability of Azure Websites. With Azure Websites, you can have almost everything you get with the Accelerator. You can host your websites on a dedicated instances, and manage them individually. You can update/deploy your website data via FTP/GIT/TFS/WebDeploy, whichever method you are most happy with. The only downside of websites which I see, is the lack of Startup Tasks and the ability to customize your environment (Windows, IIS settings, etc).
When you have set up your Azure account you can go the the web sites section and start the construction of your Azure web spaces, the interface in the preview is very straight forward to use and intuitive.
For deployment using the publish command in from Visual Studio 2012 (which I found the easiest) here are the steps you will need to undertake:
For each of your countries you will need to set up the web site
in azure.
Then for each of those web sites you have created go
to their dashboard page and download the publish profile settings.
It is these settings that you can import into you Visual Studio
solution by selecting the publish command and browsing for the
settings profile file you downloaded and importing it.
Then in future when
you right click on the web site in your solution and select publish
it will publish to your web site in Azure.
I have created a fictional website for Spain below is the link you will need in order to initiate a publish from Visual Studio.
------------ EDIT -------------
For Visual Studio 2010 I met some difficulties trying to publish, in fact the publish profile you can download was not importable to Visual Studio 2010, well at least I could not figure it out.
Instead I created a deployment user by clicking on the 'Reset Deployment Credentials' link on the Azure dashboard (see the link in the image), created the user and then published via FTP from Visual Studio 2010.
What I would like to flag up is the maintenance issue of having one site for each country rather than one site with Localization, (if it is a language issue). A small change multiplied just 20 times for 20 different countries becomes a larger task and if you have lots of little changes it soon becomes a large task to maintain them all.
I have recently started working on Sharepoint 2010 and created a 3 tier test setup (server1- WFE and CA, server2- running all service applications, server3- Database server). I used powershell commands as listed in this blog to first create the admin and config databases. After that i used the Farm wizard to provision all the service applications.
After completion all the service app DB names have GUIDs. In IIS 7, all the application pools and the virtual directories under Sharepoint web services have GUIDs. Also all the service apps are running in the same user id (domain\spservice) and i am unable to change the id for some of the services.
I want to recreate my environment and not have any GUIDs, neither in the DB names nor in IIS. I have not been able to find any documentation on how to create all the service application DBs and IIS app pools without GUIDs. The one article i found mentions how to remove the GUIDs after installation. (I am left wondering if all production sharepoint 2010 farms out there really use GUIDs in DB names and in IIS (app pools, virtual directories)!?)
Can someone please direct me to an article that outlines steps to configure a complete sharepoint 2010 environment without GUIDs in DB and IIS?
When i started out on the initial test setup I used the Farm Configuration Wizard which creates almost all the databases with GUIDs and all those GUIDs can seem overwhelming for managing the environment, for documentation etc.
To answer my question in short- the sharepoint databases can be created without GUIDs (using powershell). However in IIS, the creation of application pools and virtual directories in IIS for the service applications will have to be with GUIDs. There is no alternative for that.
I followed the steps in the article here for initial install and then used the script to create service applications from this technet article making the necessary server and database name changes.
With most of my experience as a windows web farm administrator and managing uniform naming conventions the GUID names seemed annoying initially! But since there is very little to manage or troubleshoot from the IIS interface, we do not have to worry about app pool names and vdirs with GUIDs. It is all about ULS logs, event viewer and Central Administration site!
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.