locked
Helping mitigate user site problems when moving to 64-bit SharePoint 2007 RRS feed

  • Question

  • I've read in other threads that the move from a 32-bit to a 64-bit SharePoint 2007 site is primarily an issue if users have installed code that was compiled strictly for 32 bit.

    I don't have any idea whether users have 32-bit only code installed on the 32 bit SharePoint.

    Is there documentation to which I can point them if it turns out their sites have such code?  I am aware of almost no code being developed in-house for this farm; if there are such problems, it will be more likely be due to someone having downloaded a site template or web part that has issues with the move.

    Unfortunately, it remains to be seen if the people involved with setting up the site originally, 5 years ago, are still around to assist in the tracking down and replacement of such pieces.

    Such a document might also cover other problems that users might encounter in such a change.

    I just hate the thought of users calling day and night with problems and not having some documentation to which they could turn for help.

    Monday, May 14, 2012 6:15 PM

Answers

  • No worries on the questions, that's what the forums are here for.  I'll respond as best I can: -

    1. This is one way.  You can also get a list of features via STSADM I believe.  The OOB features will depend on your version of SharePoint 2007.  Do you know if you have Standard or Enterprise?  Generally anything with a custom logo or different looking logo in the Features List is a custom feature.  If you can take a screenshot or a list, we can help out with identifying what is what.
    2. No list I'm aware of regarding OOB components but I'm sure they'll be an old post somewhere on a blog.  Features can be activated at a number of levels, from application to site collection, not the sub-site level.  Getting a list of those via STSADM shouldn't be too hard.
    3. Deployed WSPs will always show in the Solutions Management.  If it's not here, then it would have been deployed in an uncentral manner (placed in the file servers) and would probavly be be very hard to identify.
    4. Depends on the nature of the aspx page.  A few pages here and there that need to compile at start-up won't slow anything down, even if placed in the /_layouts folder.  DLLS and the like are different as they'd typically sit withint the GAC (in the system32 directories) which could potentially slow things down.

    Steven Andrews | SharePoint Professional | http://www.twitter.com/backpackerd00d | https://baron72.wordpress.com/

    Tuesday, May 15, 2012 2:56 PM
    Answerer

All replies

  • Interesting post.

    SharePoint 2007 didnt have a sandbox for users to deploy code into, so the chances of your general users deploying code into the farm is somewhat remote, unless a number of them had administrator rights.

    All a user could do (off the top of my head) is to deploy an STP, which would sit within the content database (thus it wouldn´t need to be compiled).

    I´d check at both the root site collection for any features that aren´t OOB SharePoint plus check-out the deployed WSP files to see if any third party or Code Plex solutions have been deployed.


    Steven Andrews | SharePoint Professional | http://www.twitter.com/backpackerd00d | https://baron72.wordpress.com/

    Monday, May 14, 2012 8:29 PM
    Answerer
  • Thank you for the suggestion - so by opening the root, opening Site Settings > Modify Site Settings, and then going to Site collection features, I will see the accumulation of all site features. When I do this, I see quite a number of features, most of are probably not oob. However, I don't know who brought them in or where they came from. I can search for some of these to try and locate their origin. Then I would want to contact to originators to see how to determine if their feature works on 64-bit MOSS SP 2007. That seems like a good plan.

    Is there a site that lists the OOB WSS and MOSS features that come in the box? That would help me narrow down how many of the 16 features are extra.

    The weird thing is that I think I have seen other features in other site collections that are not here.  I suppose I can begin a list, and go through the dozens of site collections to check that. But is it possible that a specific site might have features that are not at the site collection or root collection level?

    I have a question about deployed wsps. When I look in Central Admin > Operations > Solution Management I see a number of wsp files that indicate they were deployed. Can there be other WSP files that have been deployed to a farm that are not here?

    Also, do all web parts that might be added come in the form of a WSP?

    If a person - before MY time - wanted to deploy a .aspx page with .dll files, do those get uploaded directly to the site, or would they get dropped into a disk folder some place?

    Sorry for so many questions. Just trying to figure out where the gotchas may be hiding.

    Tuesday, May 15, 2012 11:12 AM
  • No worries on the questions, that's what the forums are here for.  I'll respond as best I can: -

    1. This is one way.  You can also get a list of features via STSADM I believe.  The OOB features will depend on your version of SharePoint 2007.  Do you know if you have Standard or Enterprise?  Generally anything with a custom logo or different looking logo in the Features List is a custom feature.  If you can take a screenshot or a list, we can help out with identifying what is what.
    2. No list I'm aware of regarding OOB components but I'm sure they'll be an old post somewhere on a blog.  Features can be activated at a number of levels, from application to site collection, not the sub-site level.  Getting a list of those via STSADM shouldn't be too hard.
    3. Deployed WSPs will always show in the Solutions Management.  If it's not here, then it would have been deployed in an uncentral manner (placed in the file servers) and would probavly be be very hard to identify.
    4. Depends on the nature of the aspx page.  A few pages here and there that need to compile at start-up won't slow anything down, even if placed in the /_layouts folder.  DLLS and the like are different as they'd typically sit withint the GAC (in the system32 directories) which could potentially slow things down.

    Steven Andrews | SharePoint Professional | http://www.twitter.com/backpackerd00d | https://baron72.wordpress.com/

    Tuesday, May 15, 2012 2:56 PM
    Answerer
  • 1. We have Enterprise. If we run into things that we are not able to identify, I will try to figure a way to describe them here.

    2. I will research the various stsadm options to see what might be useful here - thanks for the tip.

    3. Thanks!

    4. I wasn't as worried about slowing down the machine as I am concerned about pages that might fail when moved to a 64 bit machine.

    Thank you so much for all your helpful suggestions.

    Wednesday, May 16, 2012 12:02 PM