EV 2007 SP2, Provisioning issue

[Skee_Leonard]

I've been working with EV support to resolve this and MS but not having any luck, so here's the scenario:

Upgraded from EV6 > EV7 > EV 2007 SP2 over the weekend
I cannot get my users to provision with any provisioning configuration because it bombs trying to read our domain information. We have a single label dns name 'corporate' and the EV code can't properly extract whatever it needs to move past reading our domain to process the OU, group or windows user account to properly provision a user.
Here's the primary error message we see when trying to start the EV provisioing task:
Event Type:    Error
Event Source:    Enterprise Vault
Event Category:    Exchange Provisioning Task
Event ID:    41110
Date:        3/12/2008
Time:        12:08:42 PM
User:        N/A
Computer:    ANSSMTP
Description:
The Exchange mailbox provisioning task failed during provisioning group processing. The task has stopped.

Task: Exchange Provisioning Task for corporate

Domain: corporate

Provisioning group: <none>

Group member: <none>

Error: Unable to get DC for domain [corporate] - GetDcName() returned error code [1355]

Trace:    at EVManagedLibrary.DirectoryHelperWrapper.GetDCName(String domain, String& dcName, Boolean& bIsGC)
   at KVS.EnterpriseVault.ExchangePolicySync.ExchangePolicySyncTaskProcessor.Initialize()
   at KVS.EnterpriseVault.ExchangePolicySync.ExchangePolicySyncTaskProcessor.RunTask()

For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp

If you've seen this and know how to fix or work around, then I'm all ears.

[MichelZ]

Well, the GetDcName function is a win32 API function call, so I suspect it's not an EV related issue.
I'd guess it has something to do with DNS.

Can you query the AD records for example?

Try this on the commandline:

nslookup
set type=SRV
_ldap._tcp.dc._msdcs.corporate

Output should look like:

_ldap._tcp.dc._msdcs.corporate   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dc2.corporate
_ldap._tcp.dc._msdcs.corporate   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dc1.corporate
dc2.corporate    internet address = 192.168.1.3
dc1.corporate    internet address = 192.168.1.1

[Skee_Leonard]

I can make that query and I get the output you indicated. The only thing I see on the output that concerns me is that 2 of my remote DC's are at the top of the list. Is the order of the output significant?

[MichelZ]

OK

Could you try the following:

In EV Admin Console, go to <Site> -> Targets -> Exchange -> <Domain>
Right click <domain>, choose properties

Give him the name of a GC to use.

As for the remote DC's, I'm not sure. Have a look at the "weight" parameter, is it always the same?

Cheers
Michel

[Brian_Day]

Ok this is going back to EV7 I think and I'm not sure if it really even has to do with what you're seeing, but I'll throw it out there anyways just in case.

At the time we were told EV had issues with the way the user picker worked and it would bomb out as they were using an old function from the NT 4.0 days. The only way to do a single user was to do Domain\username, you couldn't use the picker. What didn't make sent to me at the time was (we have 14 domains), some domains worked just fine through the picker and some didn't. The domains that did not work are configured no differently and not behind any firewalls compared to the ones which did work.

[Skee_Leonard]

Thanks for the GC idea. I tried with and without but it didn't make any difference. When I do an 'nslookup' it's going to the DC that is assigned as the GC in the site settings, so it seems that it would work.

I did notice too that they were making some conversion from NT4 to FQDN in this MS API call that is failing. It made me wonder why they even use the DNS name versus simply using the Netbios name. Either way, I'll tinker with this and see what happens.

[Brian_Day]

Skee, for what its worth in the AD world single label domains cause many headaches. You might be making domain calls over NetBIOS & WINS servers instead of through DNS to get SRV records.

Make sure the (thinking hard here....) WINS 1B and 1C records are correct for the domain and this might help.

p.s.

If you aren't on Exchange 2007 you may want to migrate to a non single lable domain before you get there.

Message Edited by Brian Day on 03-13-2008 12:56 PM

[Skee_Leonard]

Brian -
I hear ya man. I have never seen this at any other gig before. I can't imagine why in the world someone would set it up like this. I inherited it and have been fighting to get it changed ever since I got here, but everyone balks at the amount of work it will take.
We're talking about an Exchange 2007 migration this year and I have already alerted everyone that the single label issue needs to be addressed first. I can't imagine how miserable that migration would be with this broken domain still in place.
Skee

[Skee_Leonard]

Problem Solved! Here are my notes back to Symantec support about what we did to fix the problem:

It’s fixed. NetBios name is the key. We had the FQDN setup for the Targets, so once I deleted that and setup our netbios name as the Domain, the provisioning works. What clued me into this is the provisioning log that we looked at yesterday. The log shows the code going out to do an ‘NT4 to FQDN’ conversion. Problem is, it already has the FQDN so of course it won’t convert. I knew NT4 never knew about FQDN, only NetBios, so it had be the domain that was causing the issue.

Also, we ran the ‘ldp.exe’ utility from the EV server to test GC functionality. The MS support engineer had me set the port to 3268 for the GC call and it was able to communicate or query the GC with no problems. We could bind to the GC and walk through the partitions as well.

I just ran the Provisioning task across our environment and all our mailboxes were enabled for archiving again.