Re: It must be simple, but...



Patience? You did not hear what I called you as I was typing my reply!

Gregg Hill



"Mocacius" <mocacius@xxxxxxx> wrote in message
news:eN3lVuJ1FHA.2540@xxxxxxxxxxxxxxxxxxxxxxx
> Thanks, Gregg. Your patience with someone that keeps saying, "Yes,
> but..." is remarkable - it really is :-) I will try exactly what you
> suggested. Sorry to be so stubborn :-(
>
> BTW, is there an easy way to transfer all the settings of a local account
> (on the client) to a new Domain account, or do I have to set everything up
> manually?
>
> Thanks again for your patience and good advice.
>
> *M*
>
>
>
> "Gregg Hill" <bogus@xxxxxxxxxxx> wrote in message
> news:ePIMQ8H1FHA.3300@xxxxxxxxxxxxxxxxxxxxxxx
>> Do exactly what I suggested and you will not be dizzy. You claim that
>> "...but in this case it'd be better if I did" regarding sharing local
>> drives. That may be the case, but you are still doing it incorrectly.
>>
>> I assume you have added both workstations to the new domain. If not, do
>> so now. If they were members of a domain before, place them into a
>> workgroup first, then add them to the SBS domain using the
>> connectcomputer wizard.
>>
>> You are not doing what I recommended. DELETE the local accounts on the
>> workstations. Do NOT "log on locally" as a local user; instead, log onto
>> the DOMAIN, using the DOMAIN user accounts ONLY. Once you log on to the
>> domain, you should be able to access server resources without further
>> prompts for credentials.
>>
>> If you want the Client1 computer user to access Client2 computer folders,
>> the easiest thing would be to add the Domain Users group to the
>> share/NTFS permissions of the remote shared folder and give them whatever
>> access you desire. Or, if you only want specific users to have access,
>> then add Client1's desired DOMAIN user account to the share/NTFS
>> permissions on Client2, and vice versa if you want 2 to access 1.
>>
>> Gregg Hill
>>
>>
>>
>>
>> "Mocacius" <mocacius@xxxxxxx> wrote in message
>> news:%23h$DiFG1FHA.1740@xxxxxxxxxxxxxxxxxxxxxxx
>>>I understand why I shouldn't share the client drives, etc., and in
>>>general I agree, but in this case it'd be better if I did.
>>>
>>> As far as the "Explanation Only" part, I even tried this...
>>>
>>> On the server - a logon was created UserName = UserN1, Pwd = trial335
>>> On client1 - a local logon was created UserName = UserN1, Pwd =
>>> trial335
>>> On client 2 - a local logon was created UserName = UserN1, Pwd =
>>> trial335
>>>
>>> All 3 user names and passwords are the same
>>>
>>> I then logged locally on client 1 and client 2 using the above
>>> credentials, and then logged both clients on the domain (when accessing
>>> the server shared drive), again, using the same credentials. Both
>>> clients had the DOMAIN account in the shares permissions.
>>>
>>> I still could not access the client drives from each other.
>>>
>>> I'm getting dizzy <g>
>>>
>>> *M*
>>>
>>>
>>> "Gregg Hill" <bogus@xxxxxxxxxxx> wrote in message
>>> news:eNslVxD1FHA.3464@xxxxxxxxxxxxxxxxxxxxxxx
>>>> Mocacius,
>>>>
>>>> It looks as though you are mixing a peer-to-peer setup with a domain
>>>> setup. Why did you create domain accounts on the server and local
>>>> accounts on the workstations?
>>>>
>>>> Remove the local workstation accounts and just use the domain accounts
>>>> you created on the server when you log into the workstations. That will
>>>> create profiles on the workstations that contain the domain user
>>>> information. You do not need local user accounts at all on the
>>>> workstations.
>>>>
>>>> What is happening is that you have set up peer-to-peer permissions in a
>>>> domain. In order for your plan to work (explanation only!!! Do NOT do
>>>> this!!), you would have to create a LUSR01 local account on the Client2
>>>> computer with the same password used on Client1, and a LUSR02 local
>>>> account on the Client1 computer, with the same password as the Client1
>>>> user. See how screwy that gets? All you need to do is dump the local
>>>> accounts, log into each workstation as the domain account you created,
>>>> and get authentication from the server.
>>>>
>>>> If you MUST share your client drives (bad move from a security
>>>> standpoint), then add the DOMAIN account of each user to the two
>>>> workstations' share permissions.
>>>>
>>>> Gregg Hill
>>>>
>>>>
>>>>
>>>>
>>>> "Mocacius" <mocacius@xxxxxxx> wrote in message
>>>> news:%236IUrBA1FHA.3892@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> Just (finally <g>) moved the LAN to a new SBS2003 Server. At this
>>>>> point, it's the only server, with 2 clients, both XP Pro.
>>>>>
>>>>> I am trying to make things work the way they user to work on NT4 (well
>>>>> similar), but I think I must be missing something very basic. To
>>>>> preface, on the recommendation from some in this NG, I purchased and
>>>>> looked through the "Windws Small Business Server 2003", by Russel,
>>>>> Crawford, Gerend, but I can't find the answers (may be because I don't
>>>>> know what I'm looking for <smile>).
>>>>>
>>>>> Here is is in a nutshell..
>>>>>
>>>>> - SBS2003 has 2 user records created on it, U_SR01 and U_SR02, both
>>>>> admin privileges
>>>>> - Client #1, has a "local" user defined as LUSR01, Drive C is shared
>>>>> for U_SR01 and U_SR02
>>>>> - Client #2, has a "local" user defined as LUSR02, Drive C is shared
>>>>> for U_SR01 and U_SR02
>>>>>
>>>>> Reboot all 3 systems
>>>>> - Log on Client#1 as a local use, LUSR01
>>>>> - Log on Client#2 as a local use, LUSR02
>>>>>
>>>>> From Client #1, through network neighborhood, I can see the SBS2003
>>>>> server, and I can access its resources after I get prompted for and
>>>>> log on as U_SR01.
>>>>>
>>>>> From Client #2, through network neighborhood, I can see the SBS2003
>>>>> server, and I can access its resources after I get prompted for and
>>>>> log on as U_SR02.
>>>>>
>>>>> From either client, I can see the other client, but when I try to
>>>>> access the HD, I get an error message that I may not be authorized to
>>>>> access it.
>>>>>
>>>>> I am probably missing something very simple, but you know, can't see
>>>>> the forrest for the trees... :-(
>>>>>
>>>>> Any hints, anyone?
>>>>>
>>>>> *M*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


.



Relevant Pages

  • join xp to 2k domain, trust of domain controler failed
    ... When you origionally joined your XP client to the W2K ... >the 2k is domain controller with active dir and dns. ... >I am using the local adm account of xp to logon the xp. ... >the domain user was successfully authenticated by domain ...
    (microsoft.public.windowsxp.security_admin)
  • RE: SBS 2K3 R2 and Outlook
    ... I understand that the new SBS domain user ... account create a new user profile on client computer. ... transfer the local user profile to domain user profile. ...
    (microsoft.public.windows.server.sbs)
  • Re: 1 SMS Advanced Client will not install...
    ... Well it turns out that those configurations were indeed satisfactory. ... couple reboots of the client machine the Advanced Client proceeded and ... > full-permissioned admin account. ... > client I was logged on as a general domain user. ...
    (microsoft.public.sms.admin)
  • Re: It must be simple, but...
    ... Transferring the settings of the local account to the domain account is one ... > (on the client) to a new Domain account, or do I have to set everything up ... using the DOMAIN user accounts ONLY. ...
    (microsoft.public.windows.server.sbs)
  • RE: configuring client users
    ... This newsgroup only focuses on SBS technical issues. ... | Thread-Topic: configuring client users ... |> computer to SBS server while we need use "set up computer wizard" to ... |> For user account issue, please understand that if you join the client ...
    (microsoft.public.windows.server.sbs)

Quantcast