Oh, I understood. My point was, the process should be the same. I can't explain exactly WHY you are getting what you are getting - but this (also from the SBS Migration white paper) should provide you a mechanism for working around it:
Create an alias that maps the source server name to the destination server name To facilitate the appropriate communication between client computers and the destination server, you must create an alias that maps the source server name to the destination server name. To create an alias 1. On the destination server, click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type: netdom computername DestinationServerName /add:SourceServerName.DomainName.local (SourceServerName.DomainName.local is the FQDN of the source server.) For more information about using netdom.exe, see "Netdom Overview" at the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=98942). Using the alias that you created, add an entry to the registry to allow SMB connections. Caution: Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up valued data from the computer. To add a registry entry 1. Start Registry Editor and locate the following registry entry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters 2. Right-click parameters, point to New, and then click DWORD Value. 3. Type DisableStrictNameChecking in the Name column, and then press Enter. 4. Right-click the DisableStrictNameChecking DWORD value, and then click Modify. 5. In the Value data box, type 1, and then click OK. 6. On the File menu, click Exit. 7. Restart the server. Regards, Michael B. Smith MCSE/Exchange MVP http://TheEssentialExchange.com -----Original Message----- From: Edward B. DREGER [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 20, 2008 10:11 AM To: NT System Admin Issues Subject: RE: extra username/password prompting after DC migration MBS> Date: Tue, 20 May 2008 09:17:54 -0400 MBS> From: Michael B. Smith MBS> It has lots of references, especially KB 884453, that you need to MBS> know about...(there is no qualitative difference between moving to MBS> a new SBS server vs. moving the A/D domain to standard, that I can MBS> think of) Thanks, but perhaps my original wording was vague or misleading. I'm not moving from one SBS box to another. (However, KB 884453 _is_ handy to know. Many thanks for that!) I converted an SBS box to Standard. That seemed to go okay. The problems began after demoting the SBS-turned-ServerStandard box. Some workstations seem to have cached OLDSERVER\username + password for authentication credentials. Specifying proper domain credentials is easy enough (albeit annoying) for shares... but not so great when logging off and a profile doesn't sync. (I've not tried accessing the profiles share directly, thus forcing a credentials request, before logging off.) I'm trying to ascertain why workstations are "getting goofy" about credentials... and why it coincides with the formerly-SBS server's demotion. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~ ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~
