Forum Discussion
How to compare two SharePoint Servers
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.
Thank you kindly for your reply! I tend to agree that expert assistance is a good idea, since I am not a SharePoint expert and have very limited experience with it from an administrative perspective. I will pursue that and see if it is possible for our organization. Thanks again for your help and advice.
