I have found that on some machines certain packages are not installing but on others those same packages are. Without logging how am i suppose to workout what the problem is.

Please help?

The /diagnostic switch is still supported, but it is no longer possible to redirect the log to a different location. Let us know if you have any follow up questions after you've had a chance to read the KB article.

This is where the issue lies

   Changed value for registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{BD52A620-C89B-4E04-8475-38295270EED1}: DynamicInfo (binary)
    Changed value for registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceCurrent: (Default) (binary)
    Changed value for registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Epoch: Epoch (binary)
    ***Cannot create directory N:\My Settings\Application Data.
    Permissions for file C:\Windows\Installer\{90120000-0030-0000-0000-0000000FF1CE}\ShellUI.MST successfully changed.
    Permissions for file C:\Windows\Installer\{90120000-006E-0409-0000-0000000FF1CE}\misc.exe successfully changed.
    Permissions for folder C:\Windows\Installer\{90120000-006E-0409-0000-0000000FF1CE} successfully changed.
    ***An error occurred installing a file
    ***An error occurred installing a file

My question is would this line be the one that stops the package deploying

    ***Cannot create directory N:\My Settings\Application Data.

Not sure where the My Settings come in as homedirectory is redirected to N:\ and appdata is redirected to \\servername\appdata$

or

    ***An error occurred installing a file
    ***An error occurred installing a file

How do I know what file it errored on?

To help shed some light I have a windows service running as the localsystem account that impersonates a domain user to download the package to the pc then the service undoes the impersonation and then builds the script file and calls the ptclient with the playscript. To call the ptclient I use a call that launches it on the winlogon desktop. The thing is the log shows

<UserName>MyImpersonatedUser</UserName><LogonDomain>MyDOmain</LogonDomain><AuthorizationPackage>Kerberos</AuthorizationPackage><LogonType>2</LogonType> 

I would have expected this to show System as the username. The ptclient processes show system as the account in process list. This works in our test domain every time, but displays the above in our live domain. It still states the impersonateduser as the username in the test domain and the same redirections apply but in the test domain I believe it ignores the redirections as it puts the files in C:\Windows\System32\config\systemprofile\application data.

any help or advice would be greatly appreciated.

It seems that whatever process you're using to impersonate a user to install the package is causing an issue because the user's full environment isn't being loaded. You said that after the package is downloaded, the impersonation is "unloaded." That doesn't appear to be happening. So the client is trying to write to a mapped N drive, but the local system account and/or impersonated user doesn't really have that mapping, so the Package can't write folders or files there. Is there a different way you can kick off the installation of the package? As long as the Prismxl service is installed, a Package will install successfully without requiring admin rights,