GarthMJ

ok, So what have you tried? what is not working for you?

You have the automatic push enabled or you have a GPO to force the install. In either case, you need to figure out which and turn it off.

Unless you say within package (not application) the deploy run from DP, all content will be cached.

I'm not following you, can you provide more details as to what exactly you are trying to do.

yes but depending on what version you are using now. That recommend might have changed. Are you using CM12 or CMCB?

Again CM uses the local computer account, you can't change its password. So exactly what account did you change its password?

CM12 doesn't have a service account, it uses the local computer account. So exactly what account did you change?

Since that is not the expected results. You will need to open a support case with CSS (Microsoft Support) directly to get support for this issues.

Are you seeing the new policies being download? For example, if the computer is off the network, the computer will re-run with the old version, why because as far as it is concerned those policies are still current.

I know that you don't like the answer but in a nutshell, it is right. Think about it. How does a CM client know that there are new source files? At a high level, the processes is a follows. Source Files are updated. CM is told to update source files CM creates the package for replication. CM update the source version within db. CM create a policy stating there is a new version for package x. DP are told to update source files DP actually get new source files. CM update the source version within db. Client contact MP and for all policies All policies are evaluated Client run package x, notices that it's version does not match package x Client downloads new source files Client run package x. If client do not see the latest version of the package then something is wrong in step 1-4. Once step 5 happens, all clients will wait for the newest source files to be on their DP once the policies are evaluated.

That would only happen if the DPs are not updated with the newest source files.

It can cause problems if you delete the source SU.

And exactly what happened when you ran the Psexec command? Did you try trying the cmd using the 32bit cmd too? It is easy to prove the timeout as it will show within the logs that the install timed out.

And what happens when you run it with the local system account? Have you contacted IBM about this yet?

Timeout issue is generally a network issue.

If email was set up during the SSRS configuration. it is a 2-second process to use email with SSRS. https://www.enhansoft.com/blog/how-to-set-up-an-email-subscription-in-ssrs

Is there a reason why are you are not using email subscriptions? To answer your question, it will depend on how you setup SSRS, as to what rights are needed by SSRS to create a file subscription. in a nutshell, give SSRS full file and share rights. the users will only need read rights.

What have you written so far? What is not working for you?

Use a CI to locate the file that you are looking for.

ok, Why don't you have normal server backups? Again why can you use powershell on computer b?

Tip, when posted log, post the whole log file and not a screenshot, The text is too small to read. You either have a problem with your detection method OR your install is spawning another thread on the computer which completes after the detection occurs. In either case, you need to figure out what is going on and fix it.

Have you asked prajwal what is wrong with his blog post? Have you checked that the detection is correct?

Ok, I will bite, why are you doing this via CM? Why aren't you doing this on the server itself with PowerShell?

Yes, you would need to adjust all collections to the newly created collection. In most companies that leverage RBA fully, only a handful of people have access to All Systems.

I'm not following you as to why they need access to the All Systems collection. Why exactly do they need access to the All System collection? What is BAU?