The “There is no software installation data object in the Active Directory” error appeared when I was attempting to add a new software package to a Windows 2008 R2 software deployment group policy but I believe it would be the same in Windows Server 2013. This was an odd one, but easy to fix none the less.
I read a number of blogs indicating that the solution was to add DOMAIN COMPUTERS with FULL CONTROL into the ACL of the source folder… but that did not work for me.
Even though I already had AUTHENTICATED USERS with FULL CONTROL, I needed to add DOMAIN USERS with FULL CONTROL. See the screen shots below:
8 Comments
Kevin · August 8, 2018 at 12:30 am
Nice and quick fix, thanks a lot!
Doc · January 18, 2018 at 3:17 pm
Didn’t even have to remove inheritable perms. Just go into advanced and reapply to all subs and files. Viola!
Emad · April 13, 2014 at 1:26 am
dear
I tried this way and its pass with me
go to active directory and computer then select administrator user add him to the RODC: Read Only Domain Controller after that go to CMD: Command Prompt type there
GPUPDATE /Force
then go back to create new package in software installation in GPMC … I’m sure it will working Properly
regard
Matt · December 3, 2015 at 1:04 pm
This was very helpful, Worked great, Thanks!
iain616 · January 9, 2013 at 2:59 pm
Hi,
I had a similar issue. Although the permissions initially appear to be correct on the share that contains the MSI. Removing inheritance and then reapplying the permissions fixed this for me.
Hope this helps
Iain616
Hilbert · January 14, 2013 at 3:34 am
iain616 you are RIGHT !!!
Same issue and your suggestion worked for me too.
Delegating full controll to Domain/Auth users is absurd.
Thanks again
Hilbert
SDE Tech · March 5, 2018 at 12:56 pm
Yeah, I thought that was a little sketchy, giving full permissions to all domain users. At the very least you are asking for some joker to delete all the files in your folder once he stumbles across your hidden share.
ian616’s suggestion of removing the inheritance and reapplying the permissions worked for me.
Dan · May 23, 2017 at 10:31 am
Thanks iain616, that did the trick. I agree with Hilbert. Giving full control to Domain/Auth users is not a great idea. Removing the inherited permissions and reapplying them to the msi file solved the problem. Thanks again,
Dan