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

We have updated ALL cmdlets within the PWPS_DAB module to require a ProjectWise Administrator login.

Since the inception of the PWPS_DAB PowerShell module, it has been our intention that this be used as an Administrative tool only. We are willing to expand the capabilities to the Restricted Administrators as well which will be available in future release of the module.

Ok, then we are stopped at 1.5.4.0 for the foreseeable future, or the "Restricted Administrators" comes alive and can be evaluated... do you have any timing on that effort? Days/Months/Years?

It is unfortunate that the both the PWPS and PWPS_DAB tools/modules are not separable by a "Admin Function" or "Anybody can" capability, really limits the use of the tools/modules and their uses.

Has there been any thought given to adding a "Encrypted Password" command/tool (similar to that Dave had provided for the "PWSync" tool that we had previously), where the logon to PWPS using "Open-PWConnection" could be passed the Encrypted Password, which would prevent the "Keys to the Kingdom" from being shared with a open Password?

A ditto for me. This will result in the PowerShell functions becoming absolutely useless. I am using PowerShell to produce dashboard reports from ProjectWise data (which are not available from Project Insights) and as this is just reporting data that is in ProjectWise and not changing anything, does not need Admin login rights. I don't have an Admin log in, and so far have not needed one.

Please do not make the assumption that PowerShell is only / should only be used for server administration tasks - there is far more to its capabilities and use than that.

Given Bentley have pushed PowerShell at us as a way of accomplishing our dashboard reporting (which were very well received at the recent ProjectWise LEARN Conference) for accessing information that ProjectWise can't otherwise, if you are not prepared to open these functions back up again to non-Admin users, then I guess I will just have to push my reporting requirements back to Bentley to solve.

Brian - +1 for including the Restricted Admins 

As an Administrator for a number of large systems I am in full support of the Admin only usage.

The PowerShell cmdlets are not yet supported under the SELECT agreement so they should be used in a controlled manner. I have seen a major outage caused by somebody using a script - even though they were an Admin user!

That said, I can see the benefits of having a tiered approach to security - e.g. PowerShell Admins & PowerShell Users with read-only functions available to the latter - as well as an Audit trail record indicating that an action was run from PowerShell but not at the expense of slowing down the fast development cycle we are getting today.

You can see from the amount of discussion in the Communities pages and at Bentley events that the PowerShell functions have become essential tools for administering ProjectWise and for me personally save many hours of work on repetitive tasks.

Limiting this to admin only is, in my opinion, going to severely restrict the benefit of the tool.  There are an increasing number of project users that have little choice than to use PS to extract data that is then used to feed Power BI.  In addition to this, three are several projects that we have that are joint-venture, and PS is used by JV partners to extract copies of the data for their records.
In both of these examples I have zero intention of making these users administrators, and neither do I want to be doing these tasks myself.

I feel that PS should simply respect the access of the user running the script, unless there is some other reason why this will not work.

Limiting this to admin only is, in my opinion, going to severely restrict the benefit of the tool.  There are an increasing number of project users that have little choice than to use PS to extract data that is then used to feed Power BI.  In addition to this, three are several projects that we have that are joint-venture, and PS is used by JV partners to extract copies of the data for their records.
In both of these examples I have zero intention of making these users administrators, and neither do I want to be doing these tasks myself.

I feel that PS should simply respect the access of the user running the script, unless there is some other reason why this will not work.

Scott, your comments and opinion are duly noted. However, please refer to Dave Brumbaugh's, previous response. 

Not saying it can't be done.  Just wondering about the wisdom of it.  Are there really "normal" users that want to use PowerShell to interact with ProjectWise? Unless everyday users have gotten a LOT more sophisticated than the last time I managed a bunch of them, I just don't see it happening.

That said, I could see a dedicated group called "PowerShell Users" or some such that an administrator would have to add you to and a switch to force a non-admin login. Will discuss with the team. 

We really appreciate all the good ideas coming from this group.

Dave

Dave, my thinking behind this is that if I could use Powershell on an external companies datasource with only the limited access rights that I had, it would be very useful. I use it on my own datasource as a full administrator, but I do not know too many companies that will allow an external party to have even restricted admin rights to the datasource that they manage.

I realise the original Powershell was aimed at Administrators and most cmdlets were designed to help with managing the server side of their tasks, but this module has expanded into documents and allowed us to run tasks that would otherwise take a long time.

Mick

Dave, It's not that "normal users" want to use PWPS really for anything... I doubt they would "get it", since we are (I am) having so much trouble trying to do "simple" tasks. As stated before a few times, all I want is to use PWPS to do the following:

1. "Periodic" Bulk Import/Export/Sync Operations on Rich Projects using a "Project Administrator" Authenticated Account under a Rich Project, where the Account has Rights to the Project, but is not PWAdmin (similar to a tool we "purchased" from Bentley that now does not function on some Projects running as PWAdmin, and is now depreciated). Audit Trail is not an issue, files may be Synced multiple times per hour to keep Data "fresh".
2. "Real-Time" Semi-Automated file Imports/Exports in the Users Context (on their behalf where possible and allowed), by insertion of code fragments into Workflows, like take a externally created ISOGEN ISO as DWG and get it back into PW, into the correct folder, updating the previous version, in the context of the user as finishing sub-application, so they do not have to wait for Item #1 above to process. The user does not need to be involved, just has to own the process... Also makes the Audit Trail more valuable.

We are trying to make it easier for users to use and interact with ProjectWise on "Hybrid" Projects (Some Apps and Files Integrated into PW, but always other Apps that are not PW Friendly still outside) where we would like the Focus to be PW.

Failure to do these means the Project Costs go up as the manual interactions go up...

Dear sir,

I need your help. how to update tagset information from excel. and data import/export to Excel.

Thanks.