Forum Discussion
How to compare two SharePoint Servers
First thing to know about SharePoint is that the servers should be thought of as a farm, not as independent servers. Everything lives in SQL, and what happens on the servers is controlled by the Central Administration console. That Admin Console is composed primarily of a configuration database. Your version 14.0.7175.5000 indicates SharePoint 2010.
"the those two servers do not have exactly the same services running, and one of them having fewer services, and that one is the Central Administration server. " - This is how it should be. Most likely the one has client requests directly, and is considered your web front-end. The other server is definitely running Central Admin as you said, and may be running other application services like User Profile Service, Search, other Application services. It sort of depends on what hardware you have, and what kinds of things you need to run as to how someone might have decided to split up the services. But only one server can run Central admin; only one server can run User Profile Service; only one can run SharePoint Server Search or SharePoint Foundation Search. Many other services may be activated on only one or both servers. All servers should be running the Timer service.
You describe a third server that was used for pushing the development code. That makes sense, and that code would have been pushed to whichever server (or servers) is/are answering client requests. Could be one or both servers, but it sounds like most likely it was pushed to only one of the two and that could be normal. Comparing the files on each server probably wouldn't be a fruitful exercise.
"can I delete the aspx and cs files from the C:\ folders on the two production servers? " No.
In your Central Admin, you probalby want to take a visit to System Settings and Manage Farm Solutions. If you've had developers pushing code, then you should see wsp's listed in there with status of deployed or installed, and deployed to listings of either globally deployed or deployed to web applications. What you don't want to see in there is "error" status on your wsp's. As long as you're seeing no errors, then your code is most likely installed where it needs to be. I'm not promising that you're good to go as long as errors aren't shown, but leads me to my next paragraph ...
It may be better to pose your questions in terms of the problem are you trying to solve. Are there errors being thrown to the clients that make you suspect the code is not up to snuff?
Thank you for your response! Very much appreciated!
I have a a few problems I'm trying to solve.
- I want to ensure that the configuration of our server farm is correct.
- I want to clean up anything extraneous on the production servers (such as the *.aspx and *.cs code files if they are not being used by SharePoint)
- In some cases it appears that the code works for one of the servers but fails to work for the other one.
For point 1 it sounds like the configuration is probably ok.
For point 2, to clarify your response, I think you are saying that once the WSP file is installed then there is no need to have any aspx or cs files on that server as all of the information related to the WSP is stored in the SharePoint database. Therefore I should, in theory, be able to delete the files that are on the two production servers of our SharePoint farm. The files should, in other words, only exist on the Development server. Is that correct?
Point 3 is a little more complicated. All of the projects that the previous developer created were bundled in a single Top Level project, so there's about 40 asp.net pages that are under the layouts folder in SharePoint. They are ASP.Net projects with code files. On the server we see that the developer copied all of the files for these projects on to the C:\ drive in 40 folders. Those are the files I think can be deleted. The reason why is that they have obsolete code in their cs files that could not possibly be functioning (such as stored procedure names that no longer exist in the database that the application calls). What we don't know directly is which server has the correct version of the code for each of these projects, and I suspect that the developer deployed the WSP files sometimes to one server, sometimes to the other. I need to find out exactly what's there currently and where required update either of the two servers with the current code. My guess is that the best thing to do is simply take the latest WSP file and deploy it to both servers to be sure they have the same code.
Looking at your instructions I have found the Solution Management Console and am lo0oking at the list of WSP files. Oddly, the one in question (where our users are having issues) appears to have NOT been deployed (please see screenshot). That's odd because the projects related (there are 40 in in the ClinicalIndicators.wsp) are actually on the servers, display in our SharePoint intranet, and do appear to function for the mots part. So if the ClinicalIndicators.wsp is not deployed... how is that even possible?
I have included a screenshot of the Solution Management console. What I would have hoped to see in the list are the dates of the deployments, but I find I can get at that information by clicking on the link that is the wsp name.
I get the following information from the ClinicalIndicators.wsp:
Solution Properties
| Name: | clinicalindicators.wsp |
| Type: | Core Solution |
| Contains Web Application Resource: | Yes |
| Contains Global Assembly: | Yes |
| Contains Code Access Security Policy: | No |
| Deployment Server Type: | Front-end Web server |
| Deployment Status: | Not Deployed |
| Deployed To: | None |
| Last Operation Result: | The solution was successfully deployed. |
| Last Operation Details: | BCxxxSRV : http://bcxxxsrv/ : The solution was successfully deployed. |
| Last Operation Time: | 4/11/2018 9:14 AM |
So that's a little confusing as well. It says it was both Not Deployed, and Successfully Deployed. What's the the distinction? Does this mean that it was deployed at an earlier point, but this version dated 4/11/2018 was not deployed?
Thanks again for your help!!
Still hoping to get a reply on the pending questions I have, if possible. Not sure if these issues are normal / common, or particular to our organization, but the current situation has left me a bit confused. Any thoughts and/or advice would be greatly appreciated. Thanks!
- To your point #2, no that's not necessarily correct. Solutions can/do deploy aspx assets to the 14/15/16 hives. You don't want to be manually removing anything from the 14/15/16 hive, unless it has been placed there manually, which would be poor practice.
We cannot tell you what you can and cannot delete as we do not know how the solutions were structured or deployed. If you're unsure, I'd recommend getting a consultant who can come in and take a look at your SharePoint farm and help you determine the best course of action.
The alternative is to build new servers and add them to the existing farm. They will pick up the WSP(s) deployed to the farm and deploy them local. In this case, there will only be the files present deployed by the WSP(s) and nothing extraneous.
That's not to say that poor development practices weren't employed and assets copied around manually. Again, this is where a consultant can really help you understand what has been done by taking a look at the source code and structure of your farm.Hey there, my apologies for not coming in here sooner ... but Trevor's response is pretty much exactly what I was going to say. I just can't stress enough how manually deleting files could land you in a world of hurt. Even if you restore from recycle bin, that doesn't mean SharePoint will necessarily use them.
When I said earlier that everything runs thru the Databases, I didn't mean to imply that all files are stored in the databases. It's more that the databases will control a lot of windows settings and how SharePoint responds to requests, but there are still files stored locally on the servers that play an important role in serving up pages.
Good luck, and I too would encourage seeing assistance from a consultant.
