Can you please provide me some steps involves using AAP with DNS.
Also we are thinking about implementing Kerberos authentication for futre integration with other application. Using AAM with DNS approach will have any issue in implementing that?

Thanks,
Datta

I relatively new in SharePoint Admin side. I need help.

I have a existing MOSS 2007 PRODUCTION intranet server name “SPServer” and the default web application (port 80) is also “http://SPServer”.

I built new SharePoint 2010 server Farm server name SPServer2010. The Default web application (port 80) is also “http://SPServer2010″.

I want keep the same name of URL after moving to production.

Do I need to change the server name and url from SPServer2010 and url to http://SPServer2010 or redirect with AAM usding DNS? What is the standard practice?

How can I change the server name and default application name From “SPServer2010″ and web aplication “http://SPServer2010″ to “SPServer” and “http://SPServer” on cut off date? These new 2010 will become production server.

Email: udatta@msi-inc.com

Thanks,

I don’t know how to create a globally solution.

What I only know about it is adding ” DeploymentServerType=”ApplicationServer”" in the root element of the solution manifest.xml file. But it doesn’t work, and the solution deployment server type is Front-end Web Server.

Thanks a lot!

To answer your question, this is a multi-server farm. The solution includes several features and assemblies which get deployed to the GAC only.

I’m aslo deploying from a sever which serves as both a WFE and CA host. No doubt this is why I have managed to get away with this.

Getting back to my original suggestion, do you think the CA features should be stripped out as a separate solution? Or should I be safe to keep doing things the way I have within my current environment?

There is a disconnect in SharePoint where while Solutions are deployed to Web applications, Features are installed on Servers.

With this in mind, deploying a Solution to a single Web Application on a Web Front End (WFE) server means all Web applications running on that WFE now have that Solution’s Features available to it. You are able to get away with what you mentioned above when your Solution does not contain any BIN or 80 deployed resources.

From your scenario mentioned above, I assume your CA Web application is running on the same WFE and your Features do not rely on any BIN or 80 deployed resources (referring to virtual directory resources).

I retracted it and deleted the current deployment. Then added and deployed only to the relevant content urls (web app root sites). Both the CA features were installed.

One was available for activation, while I used the AutoActivateInCentralAdmin=”TRUE” parameter in thwe other which also activated the feature.

Given that the solution wasn’t even deployed to the CA web application I’m left perplexed but very pleased by this discovery.

Looks like I answered my own question.

Nice description of the undocumented gotchas but I’m still seeking some practical guidance on how to deploy a particular solution I have which contains 5 features.

Three are site scoped and intended for contenturls and two are webapplication scoped, intended for Central Administration. I’m rapidly reaching the conclusion that the features destined for CA should be moved to a separate solution. Otherwise I simply don’t understand how I can avoid deploying it to CA as well as allcontenturls.

Any advice you can offer?

“When you do iireset, all Application Pools are recycled right?” Yes

“Why do we need to do iireset on each web front end? Could you please help me to understand this requirement?” Whenever your solutions deploy assemblies to the GAC, any application pools that rely on those assemblies must be recycled in order to load the new versions of the assemblies.

The SharePoint solution framework actually recycles the Application Pools automatically when the solution has installed assemblies to the GAC. Resetting IIS is most likely unnecessary, but there may be situations where the SharePoint solution framework may not recycle an Application Pool (likely because the solution was not deployed to the particular Web application), but the Web application may still rely on an assembly that is updated.

Have you noticed that when a solution is deployed to a single Web application on a WFE, its Feature Definitions are now available on all the Web applications on the WFE. This is just one case where the SharePoint solution framework may fail us and iisreset may save us. To avoid these strange cases, you can just about always count on iisreset to set things straight (at the expense of making every one of your Web applications unavailable).

At my current client, we are developing point solutions that we deploy to only a single Web application in our Farm. Since we know that only that single Web application uses the DLLs we are deploying, we only want to recycle the Application Pool for that Web application and no others.

As much as I would like to say this never happens, there have been occasions when we need to deploy emergency fixes. Being able to deploy a fix to just the single Web application becomes especially useful in this situation. We can now address the issue outside the maintenance window, without affecting the other Web applications in the farm.