Nick, Since it is a multiple AD environment, I'd assume you previously stumbled on CR 6607919. The domain join might fail intermittently in that environment as mentioned in the CR. You don't have to manually delete the computer account from the AD before joining the domain. If the computer account doesn't already exist in AD, the domain join operation will automatically create one for you. Otherwise, it will update the attribute of the existing account.
Natalie Nick Ross wrote: >Hi Natalie, > >The system finally joined the domain, but the root cause of the join >failures is a little ambiguous. > >One of the join attempts actually created a computer account in AD, so I >deleted the account before attempting another join. On the Solaris >side, aside from running 'smbadm join -u Administrator hb.acsportal.com' >numerous times, the *ONLY* other change was flushing out the cache with >'svcadm restart name-service-cache'. > >I can guarantee that nothing else was changed on the b81 system, and no >other domain admin has been logged into the lab sub domain today, so >there should not be any changes to GPOs and the AD environment should >not have changed. > >To try and see if the problem can be reproduced, I'm spinning off a VM >with b81 and will update with the test results. > >Best Regards, >Nick Ross > >Please see responses to your previous questions below: > >Is sjm-b81 a sparc machine? > > >>>x86: Sun X4500 >>> >>> > >Are you testing in a multiple DC environment? > > >>>Yes, three DCs per domain; DNS for AD domains is AD-integrated with >>> >>> >Secure Only dynamic updates; parent domain DNS uses BIND > >What's the value of the lmauth_level property of sjm-b81? (Run `sharectl >get smb`) Does you DC mandate NTLMv2 authentication? > > >>>lmauth_level = 4, network security settings in GPO are not defined >>> >>> >for NTLM session security > >To troubleshoot this problem, it'd be nice if you can configure the >syslog.conf to also log daemon debug messages. > > >>>added daemon.debug to syslog >>> >>> > >Best Regards, >Nick Ross > > _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
