We help IT Professionals succeed at work.

Potential problems with legacy ASP.net and SQL2000 applications after migrating AD from WS2003 to WS2016

I had these specific related questions after viewing Upgrading from WS2003 to WS2016 (AD issues).

It seems there is a consensus that migrating (no in place upgrades) to new a DC/DNS server running WS2016 keeping DFL/FFL at 2003 for the time being, then the legacy fileservers folders can be migrated to new WS2016 servers subsequently, and finally raising DFL/FFL 2008 then 2016 when all legacy systems deprecated.

A. There is a WS2008R2 with ASP.net framework 3.x running a legacy asp.net 2.0 app and MySQL 5.x. Push to ASP4.0 framework and it falls over.

The original strategy was to leave it in place whilst a new version is developped.   There are some references to potential problems with the application and RPC in the proposed new environment.  Has anyone come across this or offer any insights in this scenario ?

B.  There is a SQL Server 2000 running on WS2003 with a DC role, under VMWare.  The same server runs Sun Accounts v4.x.  I know there are potential issues running SQL Server 2000 in the new environment, and am concerned the Sun Accounts system whilst am told it does not directly use AD, may have RPC problems similar to 1. above.

Any feedback or insights greatly appreciated.
Watch Question

Distinguished Expert 2019
I am uncertain what you are asking as it seems to place all possible things into...
1) the transition from one DC to another does not affect applications running..
2) your SQL 2000 asp. A apps use windows based logins or Windows logins?
3) raising forest/domain level does not impact/affect member servers adversely, but the older Dcs can not be used the increase in domain/forest functional level excludes all support/functionality of a DC on an OS prior I.e. In 2008 the 2003,2000 can not exist.

I do not think you can go to 2016 and operate at 2003 domain forest functional level. If not mistaken, 2012 is the newest that can reach 2003 and co-exist...

You should transition a stage at a time, since you gave an app running in a 2003 dc.along with SQL, that is rather ....

Do you still have contact with the sql2000/asp app ...

Unfortunately, the environment and the ...
I think Because the app/sql2000 resides on a DC, I would try migrating the web/SQL first to a new member server.
Main concern when the 2003 DC is demoted, what impact it may have on the app/SQL.......if it breaks........
This is the main reason I would get the app migrated to potentially SQL 2008 as the DB can still be set to operate in SQL 2000 level.

This will achive several things transitioning the app, functionality and let you test it.
When ready, final backup/restore of the DB/s from SQL 2000 onto the SQL 2008.
You could stagger, setup the app first on the new VM while talking to the old SQL 2000 server/db.

Once the app is migrated, the remaining functions on the 2003 have to be covered ......transitioned.

What is your timeframe for the changes?
ste5anSenior Developer

In addition to Arnold's answer:

Why do you still run a SQL Server 2000? What component or service relies on it? Cause depending on this, migrating to a newer SQL Server means that you must migrate the depended components and applications also.
Distinguished Expert 2019
You can add 2016 DC servers in existing 2003 AD forest with existing 2003 DCs, that's not the problem.
Thing is you won't get support for issues any on 2003 servers

What you can do, add 2008 OR 2008 R2 DC server in between and check how you legacy applications behaving by pointing them to 2008 / 2008 R2 DCs, may be you can check with application owners / vendors
If they get success, remove 2003 DCs from environment which will clear major road block and then you will get enough time to evaluate if apps are further compatible with 2016 DCs and AD security and further deployment of 2016 ADCs


Arnold - thanks for your feedback - I am thinking it through and will post a reply soon.

Ste5an - thanks also for your feedback - its a legacy app, in this case SunSystem accounts, a former colleague advised SQL2000 could be problematic in this scenario post upgrade, but also I am looking into which MS Protocols SS4.x uses, this version seems not to be dependent on AD. RPC and DFS in particular.

Mahesh - yes I believe it is possible to add WS2016 DC to 2003 forest, I think going via 2008 and test on a VM is the way to go as you, and others, have suggested. The goal is to eliminate the 2003 servers asap, so I will need to VM test various options to see when they can be decommissioned, affected are the accounts system and a related asp.net app; the issue will be both use older versions of asp.net/RPC etc. and the accounts system I believe uses AD to authenticate logins as it has been designated a DC, the asp.net application I suspect uses a similar method but I am taking a more detailed look now to be certain. Thank you.
While there are some applications that have deep ties to AD and will have significant issues if a DC that is at a higher level than supported is added to the network (such as Exchange 2007) these are very few and far between.

For most applications a DC is a DC, wherther it be running on Windows Server 200 or Windows Server 2016.

If you still have applications running on 2k/2k3 servers that are also DCs, I would suggest moving them to "new" builds of the same operating system that are not DCs.

As regards old .net applications failing to run on modern .net, unfortunately there is no magic "make it work" incantation that fixes these, some applications can be coaxed into running on modern .net, others require a rewrite/replacement.


Taking into account all feedback, which is received with thanks, there seems to be a way forward...

1. Backup AD/system state on DC servers.
2. Install new DC in HyperV/WS2008R2 running on WS2016 base, and migrate existing AD here maintaining 2003 FFL/DFL and test.
3. Remove DC role from legacy 2003 servers and retest apps in detail, if successful decommission WS2003(1) server.
4. Install new DC in HyperV/WS2012SP2 running on WS2016 base and migrate existing  maintaining 2003 FFL/DFL for interim, and test.
5. Migrate apps from legacy 2003 (now member) servers to WS2008R2 one at a time, and retest at each step to isolate any issues. If this fails consider VLAN / SDI isolation with routing tables to allow cross workgroup access.
6. Attempt migration of SQL2000 to SQL 2008 on WS2008SP2 (running in 2000  compatibility mode) if successful decommission WS2003(2) server. If this fails consider VLAN / SDI isolation with routing tables to allow cross workgroup access.
7. WS2003 now eliminated, attempt reconfiguration of webconfig file for ASP.net 2.0 application to allow running on ASP4.x and migrate to new WS2012SP2 server.
8. Raise FFL/DFL to 2008 and test.
9. Migrate remaining WS2008 to WS2012.

Once new versions of SunSystem and legacy WebApp available in a few months..

9. Install AD services on WS2016 C Drive (not VM) of dedicated server, and promote to DC and test.
10. If successful, demote WS2012SP2 interim DC.
11. Raise FFL/DFL to 2012 and test.
12. Raise FFL/DFL to 2016 and test .
13. Migrate remaining WS2012SP2 servers to WS2016.

If I have parts of this in the wrong order, or just plain wrong, please do let me know...hoping this will be useful to others dealing with legacy apps.
Distinguished Expert 2019

Everything seems fine except below
There is no much difference between 2012 and 2016 OS and AD, step 4 is not required I believe and steps dependent on step 4 would not be required

Try to migrate apps to 2012 platform at least, if not possible then only go with 2008 R2

Else you will keep testing so long............


Hello Mahesh

Thanks for feedback. I think there is an A/B scenario here and i wrote it up slightly wrong..

Step 4 (DC WS2008R2>WS2012SP2) was included as it was suggested earlier that WS2016 would not migrate AD from WS2003, so;

a) Either migrate from WS2003 to WS2008R2 then to WS2016, stepping up FFL/DFL from 2003 to 2016 after tests successful, many experts suggest this is the preferred method, or;

b) Migrate from WS2003 to WS2008R2 then to WS2012SP2 stepping up FFL/DFL from 2003 to 2016 after tests successful.  This would only be a contingency if testing the legacy apps or other problems arose which required a WS2012 environment in the interim , for reasons other than AD compatibility, i.e. .net/RPC/DFS, and assuming tests proved 2012 suitable given the above posts.

I do agree the testing time is a problem, so the idea is to test in VM and step up a server version at a time testing each legacy app key functions until we reach a stable platform, but nonetheless I do agree it is unlikely that 2012 will be required, as for example the .net framework 4.x can be installed to 2008 or 2016, but I was hoping to eliminate both 2003 and 2008 in the process.
Distinguished Expert 2019
You may increase one hope by adding 2012 R2 dcs in between after 2008R2, it totally depends on your applications supportability
What i feel is no need of interim 2012 DCs
Instead try to migrate applications on 2012 servers

Also raise DFL & FFL to 2008 R2

You can keep 2008 / 2008R2 as DFL and FFL and later on introduce 2012 R2 / 2016 DCs with pleasure, you will get most of enhanced features on 2008R2 functional level

This will keep chance to add 2008 R2 DCs in case if required


Agree, will leave the 2008/2012R2 DC as a contingency depending how 2008 migration goes, as there are still some unknowns with the legacy apps, SunSystems is fairly well documented, but the ASP.net 2.0 app not.

Just to clarify raise FFL & DFL to 2008 R2 will not affect any 2003 member servers I can't rid of ?

Thanks .
Distinguished Expert 2019

2003 member servers will work anyway with 2008 R2 functional levels


Arnold provides the framework for final queries and main answers..Mahesh and Arne further detail...with thanks