Get-PWDocumentsBySearch : Not logged in as a ProjectWise Administrator.

See version 1.5.9.0 just posted. You can now login with New-PWLogin and use the cmdlets with a non-admin user who is a member of a group called PowerShell Users.

$encryptedPassword = Read-Host -Prompt "Enter Password:" -AsSecureString
New-PWLogin Naou22468a:PW_GAS_PRD -UserName PowerShellUser -Password $encryptedPassword -NonAdminLogin

Think I finally understood what you guys were asking for: the ability to do bulk processing against a datasource that may not be your own.  Did not even occur to me...

Anyway.  Hope that helps.  Added Sqlite support for 64-bit, too.

Dave

This does not help as the datasource admin might not even be allowed (due to outdated company policy) to add a user into that specific group. 
There must be a way to log in to a data source with the EXACT same privileges as you would have if that user logs in using the Explorer desktop app.
 
We have been using the cmdlets for years in our projects, just to get the data from our clients (so yeah, external sources and completely unable to make requests for group membership) down to our servers, and have it synced. Since we don’t want nor need to work in a PW environment. 
As for now, we are stuck with the older versions of PWP_DAB. Next step is to abandon it and use tools like AutoIT/AHK.
I mean, how did you not even think of this scenario? Just think of any possible way ProjectWise could be used. Especially for a repetitive task (more than one time in a week/month). It is not like that every single ProjectWise user is admin, true admin usage would only represent a small percentage of a total usage in a project.

Why are you stuck with an older version? The PowerShell Users group is our workaround for not requiring an admin login. I know Open-PWConnection is also less restrictive though it is limited to 32-bit.

Would adding support for a User List called PowerShell Users in addition to the Group be sufficient? I wouldn't have any problem with that, but we won't support the "any user can use PWPS_DAB" for the reasons stated above. There will always be restrictions.

Could you set up user machines with scheduled tasks that run as a tightly controlled domain user that access a tightly controlled local file with the encrypted password file for a PW service account? (the file is unique to that user and machine executing the PS). You can set up tasks to be executable by non-admins.

I think you could even set up a PS API that securely sends the password to a running process provided it's accessed by that domain account.

If they're logging into external sources at other companies this won't work, the external company controls the account you login with.

as someone wit a system with a lot of external users I would not add them to a PowerShell Users list as is.

if a separate client only tool with a separate user group/list controlling it I would consider it. a client with only file/folder operations (no acl cmdlets).

If they're logging into external sources at other companies this won't work, the external company controls the account you login with.

as someone wit a system with a lot of external users I would not add them to a PowerShell Users list as is.

if a separate client only tool with a separate user group/list controlling it I would consider it. a client with only file/folder operations (no acl cmdlets).

In v 1.14.0.0, we have added a "Report Mode" login. This is a login by a user that is not an admin and not a restricted admin and not in the PowerShell Users group. This user only has the rights to run a certain subset of cmdlets mostly related to reporting. The rule of thumb used to enable cmdlets for use by the "Report Mode" user was that they be read-only, reporting related cmdlets that were not security related with more than 10,000 executions as reported by Get-PWCmdletStatistics. This was just released. We welcome your feedback. I hope this meets your needs. Happy to consider suggestions for adding or removing cmdlets from the Report Mode list.