SharePoint
(1)
IIS
(1)
Database
(1)
Dec
(1)
Backscript
(1)
Changelog
(1)
SMIGRATE
(1)
Ecycle
(1)

Error 6553609 Backing up WSS2.0 database from SBS 2003 server

Asked By Aidan Dixon
18-Nov-09 05:28 AM
Hello, World

When I run:

extensions\60\BIN\SMIGRATE.EXE" -w http://intranet -f f:\intranet\intranet.fwp

I get this output.

15 Nov 2009 14:17:49 -0000 Site collection opened
15 Nov 2009 14:17:52 -0000 ERROR (possibly fatal):
ERROR: 6553609 You are not authorized to perform the current operation.

15 Nov 2009 14:17:52 -0000 Site collection closed

Note that this seems different from the regular cases for this error
(6553609) seen on the internet (see
http://support.microsoft.com/default.aspx/kb/828210) which seem to relate to
use of the -u/-pw options. Such options make no useful difference - in fact
if I use them I get a different message complaining that I am already
authenticated and error 6553609 above recurs regardless. I have seen only one
other internet reference to a case that matches mine but without any
solution.

Any clues, anybody?  Where should I start trying to debug this?

Aidan - I have the same problem.

Jim Frieman replied to Aidan Dixon
02-Dec-09 06:37 PM
Aidan -  I have the same problem.  The SharePoint Portal Server web server
ran out of disk space, and I had to clean up some temp files and then recycle
the MSSharePointAppPool.  After that, no matter what I do and how I log in, I
get the error:
02 Dec 2009 15:20:20 -0800      ERROR (possibly fatal):
ERROR:  6553609 You are not authorized to perform the current operation.

Any luck so far?  I am out of ideas.

Thanks,

Jim Frieman
SharePoint Administrator
Robert Half International
jim.frieman@rhi.com

Hi, Jim!

Aidan Dixon replied to Jim Frieman
03-Dec-09 11:28 AM
Hi, Jim!

Sadly I have not got anywhere with this.  I have tried other suggestions on
the net - esp. those involving -u/-pw but the issue seems to be about
authorization rather than authentication.

We have never been out of space here.  I have tried connecting https and to
the portal site too.

Can anyone suggest where to look?  The IIS log file simple records that a
401 error was returned.  Are there any other log files I could check?

Best regards,
Aidan Dixon

Have you tried using an STSADM -O Backup operation instead?

spconsultant replied to Aidan Dixon
06-Dec-09 02:00 PM
Have you tried using an STSADM -O Backup operation instead? I do
recognize you
may have specifically decided to use SMIGRATE for certain
functionality of that option.
There are some size limitation on SMIGRATE you might be hitting (size
of the content,
not out of server space).


s on
d to
a
server
ecycle
og in, I
on.
net.fwp
n.
ate to
n fact
only one
de quoted text -
Hi, yes - "stsadm -o" does work.
Aidan Dixon replied to spconsultant
11-Dec-09 07:19 AM
Hi, yes - "stsadm -o" does work.

I seem to remember our backscript used this originally but there is a
comment in the changelog for our scripts which suggests there was some issue
with stsadm which means that backups cannot easily be restored to a different
version of sharepoint - that is why smigrate was being used.  Maybe that is
not an issue after all except I had planned/dreamed/hoped at some unknown
future point to upgrade to sharepoint v3.
Post Question To EggHeadCafe