4.0 to 2003 domain upgrade issue (permissions?)

[office politics]

we have a small business currently hosting a nt 4.0 domain with 4.0 PDC & BDC, 2000 member servers, and 2003 member servers. Our clients are 98, 2000, xp. We decided to try to perform an in place upgrade of our domain to 2003. Our old domain name was FS_IMAGE and we want to change it to fmfic.com

Here's the actions we performed.

1. Imaged the PDC for fail-safe.

2. Shutdown the BDC.

3. Upgraded the PDC to Server 2003

4. Dcpromo'd the old PDC as forest root
4a. FQDN for the domain was set to fmfic.com
4b. Set function level as Windows 2000 interim
4c. Allowed pre Windows 2000 permissions
4d. Let dcpromo install and configure DNS

5. Login to a 2000 and xp workstation
5a. The domain in system properties network id tab was automatically changed to fmfic.com

5b. Ctrl Alt Del info still showed user as FS_IMAGE\user

5c. We can still access our main application server hosted on a 2k3 member server.

6. We reboot the application server to recogize the domain change.
6a. Domain name auto changed after login just like the wksts

7. We can no longer access shares on our applaication server.

7a. Access is denied using old and new credentials. fs_image\user, fmfic.com\user, user@fmfic.com, user.

environmental varable userdomain is still set to old domain name

I checked AD's Users & computers. All users and computers were there. I tried resetting the imagergt computer account in AD and rebooting the server but same results. I tried bringing the BDC back online; same results.

Locally on the server, the domain doesn't show for a location when trying to set user permissions. However, in AD on a DC, the domain would show.

Sooooooo, what went wrong here? We're thinking maybe we should have kept our old domain name when we dcpromo'd our upgraded server and then performed a domain name change. But our old domain name could have caused conflict or error because it contains a underscore, FS_IMAGE.

 

[Law]

No, I'm thinking DNS issue. Have you checked?

 

[Law]

OHHH ****, I missed some of the thing you said. This is a NetBIOS issued. You guys can ping the 2k3 member server and vice versa right? On the newly upgraded system with 2k3 is NetBIOS enabled? You might need to do nbtstat -R on the 2k3 member server.

 

[office politics]

we rolled back the upgrade as it was our live environment. I may be able to setup a test environment but it may take some time.

on the win 2k3 app server, netbios over tcpip is enabled. no wins servers. Also, the server is using our ISP's DNS instead of the internal DNS we created (which should have been changed).

i cant remember if i tried pinging the machine. But the server did show in my network places.

I'll try nbtstat -R when i get a chance again.

 

[Law]

The 2k3 member server uses your ISP DNS server just to get online though..right? You still need DNS on the DC for active directory to function and the DNS will just forward the query to the ISP DNS for internet connection. I'm not sure if your ISP let you do this to their server. But here at my place we have atleast 1 DNS server, our ISP DNS server just help resolve internet name to IP.

And I think NetBIOS is disable by default on 2k3.

 

[office politics]

the app server was upgraded from 2000 server to 2003 so maybe settings carried over as we didnt touch the lan connection properties. I did manually check this setting on the server.

All of our clients and servers are set to the ISP's DNS servers currently. Once we get AD up, I'll have dhcp assign the internal dns and forward unresolved queries to the ISP.

 

[office politics]

i built the test environment, today. I found that the PDC was running a WINS server. The PDC was the only node configured to use WINS. The PDC was set to configure NetBIOS from DHCP. These setting were carried over from the upgrade.

I set the forest root (old PDC) to Enable Netbios over tcpip.

I joined the test server to a workgroup and then added the test server to the new domain.

After completing these tasks, I was able to connect to the test server. I'm not sure which of these made it work but ill have to do it again sometime reral soon to our live environment.

thanks for your help law.

 

[Law]

I think you fix the problem by enabling NetBIOS over TCP. If you set it to default it would use the NetBIOS setting from DHCP server therefore if DHCP server had some bad configuration it would carry on to which ever DHCP client uses the Default netBIOS.

Anyway, at my place we disable netBIOS and we don't use WINS server. We use the internal DNS to map computer name to IP address and we just create a MAP script on the user login so the user can just automaticly connect to the share. It was for security reason.

 

[office politics]

I think you fix the problem by enabling NetBIOS over TCP. If you set it to default it would use the NetBIOS setting from DHCP server therefore if DHCP server had some bad configuration it would carry on to which ever DHCP client uses the Default netBIOS.

since it was a server, it was setup to use static ip config.

i may have goofed on the test env tho. The test app server is 2000 server, but the live app server is 2003 server.

 

[Law]

I'm thinking a newly install Windows OS won't have any NetBIOS cached. Therefore at the time you may have synchronized in your test environment.

But your live environment has already been implemented before the newly upgrade, and probably the NetBIOS configuration didn't clear or synchronize with the information that the new server announced.

So if you have problem connecting using "My Network Place", netBIOS is to blame. Most of the time it can be fix by clearing the netbios caches and arp caches.

I don't have an overview of your network topology and scheme, but from the things you were encountering I would definitely expect it to be netBIOS. Not too sure why it kind of just work in the test environment. NetBIOS is sometime unpredictable.

If you have WINS running you need NetBIOS over TCP to work.