Your Win2K3 server is authoritative for the
example.com zone, so when a request comes in for something in
abc.example.com, it's going to see that it is an authority, look to its zone records, probably not find a match, and return NXDOMAIN to the client.
You need to first make your authoritative domain understand that it is not authoritative for the
abc.example.com subdomain/zone. To do that, in the
example.com domain, add a New Delegation for
.example.com will be appended automatically). You will be required to enter a FQDN for the
abc.example.com name server(s) and one or more IP addresses if the FQDN doesn't automatically resolve. The UI will complain if the DNS servers you point to are not authoritative for the zone, but you can proceed anyway (i.e. one or more are slaves).
The delegation will create the NS records for the
abc.example.com zone in the parent
example.com zone automatically, as well as any needed "glue"
AAAA) records to point to the child zone's DNS servers. This is sufficient for other recursive DNS resolvers to find the
abc.example.com DNS servers. However, workstation clients using your Win2K3 server as their resolver won't follow the glue records; they need your server to do the recursion for them. But your server doesn't know to do the recursion yet.
Windows Sever 2003 introduced a feature called Conditional Forwarding. This allows you to specify the specific DNS servers that your server should use to handle requests for specific zones. In your case, you would also add a conditional forwarder for
abc.example.com and point it to the same IP(s) of that zone's name server(s). Without this step, workstation clients will receive NXDOMAIN answers. If you don't do the delegation step first, attempting to create a conditional forwarder may fail since the server is authoritative for the parent zone and would also be authoritative for the child zone without the delegation in place.