MSI deployment fails after DCPROMO

[cookie_monster]

Introduced a new DC a couple of weeks ago (2003 SP2) and have transferred all FSMO roles over and set it as the new DNS that all workstations use the system has been running well so it was time to DCPROMO the old server, the demotion went fine with no errors, netdiag and dcdiag all check ok on the remaining DC's and i've confirmed that the FSMO roles are on the new box.

The old DC held some shared areas and a share containing MSI applications for deployment, since the demotion msi files will not deploy from this server (i can access them manually) but it is accessible as a file server drives map ok and no other errors. If i move an msi package to another server (same permissions) and create a share it will deploy ok from there so i'm sure that the GPO's and DNS are operating ok. I've checked all of the resource records and flushed the DNS cache (the IP hasn't changed but thought i'd try) after this i can still ping the server and access it in every way but packages still fail.

I've been having a read of the document below and am starting to think that it's a kerberos issue SEE: Appendix C: Troubleshooting, Problem: The Application Event Viewer indicates errors that the MSI package installation failed with an error ‘Package source not located’.

I can't try this untill tomorrow but wondered has anyone had this issue before?


http://home.fnal.gov/~jklemenc/dl/AD...or-Dummies.doc

.

[GrumbleDook]

2 or 3 things to try.

The old box but a new folder shared under a different name and ACLs set from scratch ... does this work?

The original folder has the share dropped and ACLs reset, reboot the box and then add the same share with the correct ACLs set.

Finally, remove the box from the domain, remove all shares and reset all ACLs. Add it back to the domain, recreate shares, reset ACLs and go again.

Had to use all 3 of the above at one time or another for similar problems. Probably a simpler solution but it sort of worked ...

[cookie_monster]

I've already tried a new share on the same box with new ACL's and it didn't work.

I haven't tried removing the box from the domain yet as it's now back in use so i'll have to try that later, all of the other shares are working as they were before.

Cheers.

[SYNACK]

Just checking, have you checked the permissions on the distribution share allow domain computers and the everyone group. I had issues where new computers that had just been joined had not had their group membership replicated to to the server that was shareing the files and so was denying them access at first.

The kerberos issue should only apply if the full dns name was used when the application was deployed and should be fine if you have used the machine name.

[cookie_monster]

This server was used to deploy software this morning right before the DCPROMO and it worked just fine i then performed the DCPROMO and the issue started nothing changed in between so the same ACL's that have been working are still set.

The share has everyone set but i've never had domain computers and it's always worked ok. I'm seeing this with clients that are already on the network and new builds as well.


@ Tony: did you see this after demoting a DC as well?

Cheers guys.

[GrumbleDook]

After removing it from the domain I waited over a weekend for all records to be scavenged before adding it back on.

I did consider doing a manual scavenge but couldn't be bothered, and hoped for the best.

The first two usually sort things out though.

One other thing to try that I never did (but was told it could be an option) is to use the IP address instead of the FQDN.

[cookie_monster]

I think i'll head in early and remove and rejoin it to the domain, the DC will have been demoted for over 24 hours by then.

[cookie_monster]

Hmm well i've removed the server from the domain rebooted then rejoined and recreated the shares but the packages are still failing. Every other share is still fine



EDIT: Hmm hang on it seems to of sprung to life.