Turn on Windows Auditing & see where that leads you.
If you see the user name being rejected that you're trying to connect to the share with, I'm guessing you need to either update the credentials stored on the Core or unlock the User in AD (possible someone did something that caused the user to get locked & thus the server would not accept those credentials).
Thanks for your help
If I add the everyone group in the access rights of my prefered servers zone (Read and execute) , the distribution is ok.
The system account is present in access rights but apparently it's not sufficient, however it is the account which installing software on landesk task.
This problem was not present in 9.6 SP1
I'm not quite sure I make sense of your response. (Granted - I'm knackered, so could be me )
So the "Local System" account is only really relevant for installing the software once the files are downloaded on the client (assuming you've chosen the default "install as local system").
In order to download files from a Preferred Package Server, you should give the Preferred Server a set of credentials to access the share with ...
... so you're not going to be (/shouldn't be) hitting up the share as "Local System" if you've got those credentials defined.
That's why I suggested you turn on auditing. To make sure that the client is knocking at the share with the account you specified ... (and if so - chances are it'll fail because the account is either locked or hasn't got rights to the share).