I'm not sure if this should be posted here or over superuser, but how does one go about mirroring a Sharepoint 2007 site? I have admin access, and the mirror doesn't need to be nice and pretty; it just needs to be presentable and readable. Also, I need all the shared docs to be copied as well.
We use to have WinHTTrack to mirror the Sharepoint, but that broke a few months ago due to some of our recent security changes. I tried the username#password:domain method but that resulted no luck.
It depends a little bit on how and where you want to mirror it.
If you have a separate SharePoint farm (even a single server - one tier - farm), you can rely on backup / restore, export / import or content deployment to have another copy up and running that will be a mirror of the existing one.
If you want an offline version, depends on what kind of content you need (collaboration stuff ?) you can use Microsoft Groove 2007 that offers an offline mode for some of the targeted data.
I've found this great tool that can mirror the SP site for cheap: http://www.metaproducts.com/OEPR.html
If WinHTTrack did satisfy you, why not just fix it?
There are solutions around the web to have WinHTTrack work with NTLM authentication: http://forum.httrack.com/readmsg/7513/index.html
However the download link seems to be broken (geocities..), but you could try to search for NTML proxy solutions and try to setup your own.
Related
We have a company SharePoint site that we paid a company to configure and setup for us. We are slowly taking over more and more of the administration of this site. We would like to setup a test environment so we can make changes with out affecting daily business.
How can we take what they have already installed, deployed, and configured and make a copy of it?
I know we can backup the database, but what about the stuff the downloaded and deployed into the system?
None of what they installed are paid applications from what i can tell. They look like the base applications from the Microsoft SharePoint site like Case Management, Knowledge Base, and a few others.
Thanks
You should take an inventory of the installed solutions, you can see that in the list of solutions under central administration. Then try to identity 3rd party solutions and get the WSP files (I bet they are stored in a folder on your server :))
Set up a new environment, make sure to install exactly the same version, including any service packs and/or hotfixes. You can get that list when you search for the version number in Google (the version number is usually seen in the Site Administration page).
After that, install your custom solutions and attach the content database, this should be it.
We'll be upgrading a client's MOSS public internet site soon from a Cumulative Update to SP2 and are conscious that there will be downtime (to perform the upgrade and possibly troubleshooting!). We would like to add a holding page so that visitors still get access to key contact details and a message that the site is under maintenance.
Does anyone have any tips for doing this type of thing with SharePoint? I know of the app_offline.htm file that when dropped into the web root, will automatically prevent access to the rest of the site but wasn't sure if this was standard practice in the SharePoint world?
Any tips?
Cheers, James.
If the app_offline.htm works for you, then by all means, use it.
I think that it will the best option for you, and to the best of my knowledge SharePoint doesn't have any other means of putting itself offline.
As this is a public intranet site you are updating, presumably there is already a test environment for it that is close or the same in configuration. It is important to follow exactly the same steps for updating the test environment as you would for production. These should be documented as well and followed to the letter to reduce the likelihood of mistakes. This way you are much less likely to run into problems.
I would try app_offline.htm as you suggest (like Magnus I don't believe there is another way to take SharePoint offline). If your test environment updates with this in place you should be fine.
I have created a new SharePoint 2007 MOSS Intranet. Our admin people are purchasing backup/restore software and I will eventually have to verify a restore of the farm backup they create. Has anyone got some suggestions on a best practice for this? Ours is a small 2-server farm built with VMWare VMs on SAN. How will I know that the restored version is a duplicate of the original in every way and what should I look out for?
In answer to the remarks:
There's no checklist. The problem is the dynamic nature of SharePoint. Team Sites come and go, as do documents and libraries. Who's to say one of your users didn't delete a document library and then you think after a restore something is missing.
I think the best bet would be to require your users to do a quick scan after a restore, see if they miss anything major, like sites or libraries that are supposed to be there. You yourself could have a "homemade" checklist that you follow to check if all major features deployed by you (features, timerjobs etc.) are still there.
Is it best practice to not use C:\Inetpub\wwwroot\wss\ for SharePoint? My concern is that the configuration wizard seems to look for this C: path and it may be too complicated to not use the default path(s),
What would be the reason for using an alternate location?
You should not be changing anything in the sharepoint IIS sites through IIS Manager, except through the sharepoint Central Admin site. There are dependencies in the sharepoint configuration that are not just stored in IIS, especially around the users that are applied for app pools etc. This website does most of the things you need to do (i.e. host headers etc)
So best practice is to create a folder in the C:\Inetpub\wwwroot\wss\ that is easy to map to the web application and then leave the folder as is.
Although it is hard to find stuff in the Central Admin site, the Infrastructure Update for SharePoint helps.
Having failed miserably in the past merely trying to change machine names on a VM after Sharepoint was installed, it is hard to imagine a goal more likely to frustrate than this idea!
The only arguments I've heard for not running IIS websites out of the Inetpub directory is that it's a commonly known location for evildoers to look at when attacking a system, but if security is your concern you're far past screwing the pooch if an attacker has file system access.
We've always let the configuration wizard pick that location for us. There's a lot of aspects of the underlying configuration that rely on that location and it's never seemed worthwhile to explore changing the home directory.
I applied the MOSS infrastructure upgrade w/o applying the WSS one before it -- uh, help!
Quoting:
Infrastructure Update for Microsoft Office Servers (KB951297)
Other Relevant Updates It is strongly recommended that you install the Infrastructure Update for Windows SharePoint Services 3.0 (KB951695) before installing this update on any of the Office Servers listed in the system requirements section above.
Therefore not applying first Infrastructure Update for WSS seem to be not recommended but not unsupported
I believe that is a supported, but unrecommended configuration. You should be able to get help from microsoft :)
I am assuming that you have also run the Configuration wizard after you applied this and brought your system online? If you have not, you are in a much better position, as you can apply the WSS upgrade - then run the wizard and you should be fine.
If you have run through the wizard - and brought the system back online - its not the end of the world. What you will want to do - is go back and follow the steps to upgrade your system just as if you had not done anything. The infrastucture update makes some significant changes and improvements to portal search - so once you start trying to configure that, you'll see some errors in crawling etc - as the indexer (which has been updated) tries to crawl content (which has not).
Apply the WSS bits, then reapply the bits for MOSS, then run the Config wizard and bring everything back. You should be okay at that point.
Obviously, before you do anything, backup all systems and take them offline.
Hope this helps.
Sounds like time for a full restore. The MOSS upgrade steps did explicitly ask for a restore, didn't it?
The TechNet article Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007) has a dicussion on this in the community content section. Someone commented that the WSS update must be run first. There is no suggestion for what to do if you don't or what the consquences are.