Re: useraccountproblem with migration

With STS you added the users to the STS site and it did indeed automatically
create them on the server.

In WSS they removed this as they didn't really want people to have local
users on the server because they expected people to use multi front-ends. So
in WSS you have to first create the user on the server and then you can
assign them to the site.

If I understand your other pont correctly when you transfer everything with
smigrate they all get roughly the same new date and are all uploaded by you.

But when new stuff is added in WSS it's just as before. It still specifies
who adds or amended things.

Engelbert

"login1" <login1@xxxxxxxxxxxxxxxxxxx> wrote in message
news:1132859099.81228@xxxxxxxxxxxxxxxx
> The problem (and a big one) is that you can't see anymore who have posted
> what on the sites. There are a lot users and the information who uploaded
> it is just gone.
> For a system made for group collaboration this is a big problem.
>
> With STS, it made those local users for you I thought, you didn't had to
> create them, just create a new user in STS itself.
>
> Engelbert wrote:
>
>> When you migrate from STS to WSS you anyway lose user authentication
>> information.
>>
>> Add to that the fact that you are going from users local to the STS
>> server
>> to AD users and you will definitely need to re-input all users manually
>> to
>> your WSS system.
>>
>> There is no "fix". There is however a major advantage for you in moving
>> to
>> AD users namely that you need only give them access rights to the WSS
>> site
>> and don't need to specify a password. With local users you would have to
>> create them first on the server (with password) and then give them access
>> rights to WSS.
>>
>> Engelbert
>>
>> "login1" <login1@xxxxxxxxxxxxxxxxxxx> wrote in message
>> news:1132784053.784989@xxxxxxxxxxxxxxxx
>>> Hi all,
>>>
>>> I did a migration to the new sharepoint WSS from sharepoint STS.
>>> I have problems with the user accounts.
>>> Those were local accounts so they aren't created automatically in the
>>> new
>>> one.
>>>
>>> I created first those logins before migrating but the problem is that
>>> the
>>> domain is in the new login and the machinename of the old server in the
>>> old
>>> accounts.
>>>
>>> So I had for example:
>>> \\machinename\user1
>>>
>>> and on the new server it is:
>>> \\domainname\user1
>>>
>>> so the users can't be imported even if the usernamepart is the same
>>> since
>>> the rest is different.
>>>
>>> How can I fix this?
>


.

Relevant Pages

  • Re: Discussion Server and Office 2k
    ... I can confirm that I am using Sharepoint Team Services v1 and not WSS. ... I don't have access to the server at the moment, but I believe that is the ... > isn't such a thing in STS unless you created a Discussions List and called ...
    (microsoft.public.sharepoint.teamservices)
  • Re: Migrating SharePoint
    ... install WSS on top of STS ?? ... WSS FAQ site / Useful Documents / MS Articles / Downloads). ... then should install WSS on a separate server (see the WSS FAQ for how to do ... Updates to the STS server it fails. ...
    (microsoft.public.sharepoint.teamservices)
  • Re: Home Page "Under Construction"
    ... > STS does not come free with Win 2003 Server, that's WSS (Windows SharePoint ...
    (microsoft.public.sharepoint.teamservices)
  • Re: Move a WSS site to another location/network (including AD users)??
    ... old accounts with the new ones. ... WSS as an underlying infrastructure and deliver it to our customers via ... server which is a DC, SQL server and DNS server currently in our ...
    (microsoft.public.sharepoint.windowsservices)
  • Move a WSS site to another location/network (including AD users)??
    ... WSS as an underlying infrastructure and deliver it to our customers via ... server which is a DC, SQL server and DNS server currently in our ... accounts have become the issue. ...
    (microsoft.public.sharepoint.windowsservices)