Hi Daniel,
Thanks for taking the time to respond. I've responded inline but think I need
to stress here that these are not just my problems. Neither are the problems
limited to what's discussed here. This is, after all, just one small facet of
administration. Everywhere you look on the web people are complaining about
these and other issues, as is evidenced by the arrival of so many third party
apps and tools to fill the void.
Ø Having now tried several tests through UI (and received only errors) and
STSADM (and seen the hell that breaks loose afterwards) I've gone down Uzma's
path of only backing up individual sites and restoring to dev as required for
testing and development. Hardly ideal
What Errors? Did you deploy the existing features to the new environment,
ensure all DLL's are in the right spot/place, etc?
Trying to perform a simple backup on a single web app I get the following:
The backup/restore job failed. In order to rerun the backup/restore the timer
job must be deleted from the Timer Job Definitions page. Failure Message: The
backup job failed. For more information, see the error log that is located in
the backup directory.
The essential log info follows. Just to confirm I am logged into the server and
CA as the SharePoint Setup account and am only trying to backup our primary web
app, not SSO or anything else. Looks like this account doesn't have sufficient
access but do you think any of our sys admins can tell what account does?
Unfortunately they're even more clueless as to the inner machinations of MOSS
than I am.
[11/19/2008 2:58:17 PM]: Error: Object SingleSignOn_DB failed in event
OnPrepareBackup. For more information, see the error log located in the backup
directory.
SqlException: Cannot open database "SingleSignOn_DB" requested by the
login. The login failed.
Login failed for user 'SYD-CENET\sharepoint.setup'.
[19/11/2008 2:58:18 PM]: Error: Object
WSS_Content_intranet.ceosyd.catholic.edu.au failed in event OnBackup. For more
information, see the error log located in the backup directory.
SqlException: Cannot open backup device
'C:\ProdBackups\spbr0000\00000015.bak'. Operating system error 3(error not
found).
BACKUP DATABASE is terminating abnormally.
[11/19/2008 2:58:18 PM]: Completed with 2 errors.
[11/19/2008 2:58:18 PM]: Error: Backup failed for Object
WSS_Content_intranet.ceosyd.catholic.edu.au failed in event OnBackup. For more
information, see the error log located in the backup directory.
I'd do a sitecollection backup but it's too large for that as I can't exclude
the doc library content. (My main gripe.) Being unable to change the regional
settings in CA in a supported way is another. I mean did someone just forget to
include the link to regionalsetng.aspx? :)
Ø With publishing sites (and quite possibly WSS w/ publishing enabled) this
still requires running custom STSADM commands and other fixes to correct page
layout paths (break page settings), CQWP queries, hundreds of hard-coded links
within web part fields or pages (because MOSS wouldn't allow a relative URL!)
and more. And let's not forget about the lack of support for tasks and
workflows.
Sounds more like a issue of someone has instead of using relative paths, used
hard paths, Hardly a fault of MOSS. Could you give an example of where MOSS has
a hardcoded URL? As I know that this is something they wish to address in
upcoming versions.
For layout pages these paths are not set by an end-user. We're talking about
internal paths to content in the master page gallery set by SharePoint. This
will actually prevent editing Page Settings for any page in the collection.
As for other paths, I'm referring to a number of fields (e.g. Send To...) which
do not allow a relative path. Of all the fields in SharePoint to have
validation applied, they go and stick it the ones that don't require it. I'm
also referring to breakages within the Content Query Web Part (and others based
on it) that require reconfiguring, especially if they've been in any way
customised.
There are also others that escape me now.
Ø I cannot get over the sheer amount of hard paths and absolute URLs that MOSS
uses. That simple environment variables or tokens for {siteroot}, {site},
{_layout} etc., are not used simply amazes me.
~Site, ~SiteCollction, /_layouts (accessible from any path or folder in the
URL, i.e. ~Site/_layouts/page.aspx)
As per a number of recent posts on this it's been established that none of
these can be used, neither in any of the locations mentioned above, nor in any
useful way within a layout page. A choice example follows:
<a
href="~sitecollection/SiteDirectory/SitesList/NewForm.aspx?Source=~sitecollection%2FSiteDirectory%2FPages%2Fcategory%2Easpx">Add
Site</a>
Ø It's insulting enough to pay this much for a product and then be left with a
command line tool for all these operations, but to the have this many problems
with something as simple as a backup and restore operation...
Backup & Restore is not as simple as just export and import, it relies on
DLL's, features and solution dependencies. If a dependency is invalid or
missing, it will not restore (imo it makes sense).
Your explanation is the very problem. It's not simple. Not by a long shot. But
it doesn't need to be this hard and it's clearly not helped by the fact
although 99.97% of what you need is in the database(s), the rest of it is
strewn to the Four Winds.
The greatest difficulty I have had thus far is simply determining exactly what
is and isn't backed-up. Selected DBs, web apps, GAC dependencies (they're all
signed after all), web configs, logs? All MSDN can suggest is that you also
purchase Microsoft System Center Data Protection Manager.
A backup should not rely on anything. These items should be inclusive. I mean,
either it's doing a full backup or it isn't. Which is it? Custom binaries I can
understand but surely the 12 hive should be considered an inclusion, or at
least an option. And all this just to perform a backup. Let's not get into what
happens when you attempt a restore, particularly to another location.
And, if you get as far as restoring, and something vital is missing, shouldn't
one expect a detailed explanation of just what? And the option to proceed at
your own risk regardless?
Ø Why would it have be so hard to create a web-based GUI for theses (and
other) essential daily tasks that allowed a bit more control over the various
parameters and managed syntax while also providing a "Test" mode for the less
brazen?
Central Admin under Backup/Restore? Or Item level backup/restore level with
DPM? Or even batch script with use of STSADM to run on a schedule.
STSADM could of been made to support item level backup/.restore, but the amount
of effort/overhead involved in this via a CLI is pretty large, Should the UI
have supported it? Yes It should have.
You said it. A fully-fledged set of screens within CA that allow all the
options already discussed.
------------------------------------------------------------------- OzMOSS.com
- to unsubscribe from this list, send a message back to the list with
'unsubscribe' as the subject.
Powered by mailenable.com
