Conference iosg::all-in-1_v30

    Alan,
    
    What error messages if any were in the SFCP Migration Log?
                  
    regards,
    
    Andrew.D.Wicks

    Do they get the problem if they run /NOCUST?
    
    Have the SFCP customisations to the link been removed?
    
    Cheers
    
    Stuart

Thanks for the replies Andrew + Stuart,

They have no errors in the migration log - the only strange thing was that 
at the end of processing each SFCP cabinet it said:
Removing SFCP access controls
SFCP cabinet [EXAMPLE] has been converted to drawer [MANAGER]MAIN

this is not actually the case, they are in the original SFCP profile cabinets,
so I dont know where [MANAGER]MAIN comes in at all.

/NOCUSTOm makes no difference.

I have asked them to relink after making sure there were no sitelink.coms of
any version (just in case). They have not customised any of the object
modules. Awaiting response.

Cheers so far.

Alan

    Alan,
    
    Oops that doesn't look good at all the messages should be
    
    SFCP cabinet [EXAMPLE] has been converted to drawer [EXAMPLE]MAIN
    
    i.e it just tacks a MAIN on the end. Is the SFCP_SAC file still there
    and could you just try running the migrate again with trace on or
    something - unless Stuart has a better idea of course ...
    
    Regards,
    
    Andrew.D.Wicks

    There is another possibility. If the NEWDIR failed then OA$USER is 
still pointing to the account that you used to do the convert. This 
could happen, I suppose, if you were converting several (hundred?) 
cabinets but the first several (hundred?) should be ok. If this is the 
case it is the global buffers problem and we will think about it. If 
this is not the case then try, from the managers account, NEWDIRing to 
one of the SFCP cabinets. If it fails then that is why the tool 
failed. Let me know if either of these happen and we will take it from 
there. 

Cheers, 
jal

Hi guys thanks for the interest,

Well they didn't have hundreds of SFCP cabinets - they actually  only had
11 and they have about 60 profiles altogether.

The thing is the documents aren't in the MANAGER account - the migration worked
to a greater extent (after re-seeding) than it failed. At least thats my
interpretation of the log file - see extract below.

Converting cabinet DOCA1

User BERRY_C has been added
     Drawer access    RWD
     Document access  RWD
then various other users as above
Processing Documents
0 Documents processed
Removing SFCP access controls
SFCP cabinet [DOCA1] has been converted to drawer [MANAGER]MAIN.

Also should they have to specify the Drawer as [DOCA1]MAIN and the FOLDER as 
[DOCA1]'folder' to see these documents.

I have asked them to newdir to the SFCP profiles and there is no problem
doing that - and in fact if you do a Send of the documents once newdir'd that
works fine.

Then got him to actually log in as the SFCP account ( not sure if that is valid 
but....) and try the Send. That gives errors against deleting a zmumble.txt file 
in [.MSG]. I have the full messages if necessary.

Any more ideas from the floor....

thanks in advance

Alan.

Ps they can workaround by refiling problem documents into another drawer but they
still want to know what is happening.

Alan, 

    Could you do a dir/acl from a priv'd account on the ALL-IN-1 
directory, one of the [.DOCn]subdirectories and one of the documents 
in the [.DOCn]subdirectory? I would like to see what the ACLs look 
like to see if there was an error building them. 

Cheers, 
jal

re .6
Alan, 


>Also should they have to specify the Drawer as [DOCA1]MAIN and the FOLDER as 
>[DOCA1]'folder' to see these documents.

This is not what they want to do! This will attempt to use the old 
V2.4 shared folders. If the original cabinet name was [DOCA1]folder 
then the drawer name is [DOCA1]MAIN (or whatever the default drawer 
name in on your system) and the foldername should just be "folder" (no 
quotes or brackets or anything. 

If the foldername was [DOCA1] without a folder name after it then the 
drawer name will be the same and the folder name will be DOCA1 without 
brackets or quotes. This is because we can't leave the folder name 
blank. If this is not what they actually want to call it you can 
do a RFF (Refile Folder) and change the name. 

Cheers, 
jal

Sorry for slow response....busy busy

They cannot select these documents unless they put
[DOCA1]'folder' in the Folder field.

So from what you say it looks like they haven't been 
properly converted....

ACL layout

[BWGEN.DOCa1]DOC0.dir   [a1_sfc,bwgen]       (RWED,RWE,E,E)
    (Identifier=[a1_sfc,bwgen],options=default,access=read+write+delete+control)
    (Identifier=[a1_sfc,bwgen],access=read+write+delete+control)
    (Identifier=[a1_usr,berry_c],access=read+write+delete)
    (Identifier=[a1_usr,berry_c],options=default,access=read+write+delete)

[.DOC0]Zmumble.wpl      [a1_sfc,bwgen]        (RWED,RWED,,)
     (Identifier=[a1_usr,bwgen],access=read+write+delete+control)
     (Idenifier=[a1_usr,berry_c],access=read+write+delete)


they are RFDing but they still want to know what has gone wrong.

any more ideas 

thanks Alan.

    If the documents are still in the folders marked [user]folder then 
the migration tool did not work. It ran in part because the ACLs were 
applied correctly. It seems that only the RFDing failed. I have had a 
look at the script and I can't  see a way for this to happen. 
    
    Can you log into the SFCP cabinet accounts? If you can could you 
post an index of folders?

    Are the SFC_SAC.DAT files still in the default account 
directories?

    Is there any possibility that we can log into their system? 

    Once the documents are refiled everything should work from what I 
can see. I cannot figure out why it wasn't done especially since the 
account was NEWDIRed to the acls were set based on the SFC_SAC.DAT. 
The only thing left to do was the Refile. 

    This wouldn't be one of those accounts where there are no DOCn 
subdirectories for the documents would it? 

Cheers, 
jal

Hi John

thanks for coming back on this one....

An index in the account actually fails because of no disk quota
but if you mean how do the documents appear they are in drawer MAIN
folder [GEN]ASSI V.
They do not have the sfc_sac.dat files. 
The ex-SFCP accounts do have the .doc0 - 9 dirs

It all seems ok but.....

Anyway I think if we can manually finish the job they will let it
go - so do you think all that is needed is to make a script that will 
refile all the docs (based on part of the SFCP_CONVERT_ACL.SCP)
and run it for each ex-SFCP account. Any comments

Thanks Alan.

	
>
>Anyway I think if we can manually finish the job they will let it
>go - so do you think all that is needed is to make a script that will 
>refile all the docs (based on part of the SFCP_CONVERT_ACL.SCP)
>and run it for each ex-SFCP account. Any comments

	I don't know what happened but it looks like the refile should 
fix the last of it. Make sure the documents have the correct ACLs on 
them as well. One way to ensure this is to share the drawer. Even if you 
don't make any changes but don't exit the document ACLs will all get 
updated. 

I hope this helps. 

Cheers, 
jal