update-PWFolderSecurity not found.

I will try the 64 bit angle...the hyphen; there or not, gave me the same error... Thanks!

ok, I uninstalled the x86 and set up the 64 bit....same error (with Hyphen)

PS C:\PS> Update‐pwfolderSecurity

Update‐pwfolderSecurity : The term 'Update‐pwfolderSecurity' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was
included, verify that the path is correct and try again.
At line:1 char:1
+ Update‐pwfolderSecurity
+ ~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Update‐pwfolderSecurity:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

PS C:\PS> get-help pwfoldersecurity
Security Protocol now set to TLS 1.2
PWPS_DAB Version is 2.0.6.0
This is a 64-bit process.

Name Category Module Synopsis
---- -------- ------ --------

Update-PWFolderSecurity Cmdlet pwps_dab UpdatePWFolderSecurity is used to add user(s), group(s), or userlist(s) access control to specified folders.

So the cmdlet is not case sensitive. The reason it was not working in your examples was because of the dash

Update‐pwfolderSecurity

Update-PWFolderSecurity

It might not look like much but the first dash is shorter. Almost like it was copied from a file that had a different font, a half dash, which I did not know existed. If you were to copy the above into PowerShell and look at the dash you will see what I mean. The top one is a shorter dash. So even if you copied the top line and did the correct capitals in the cmdlet, it would still not work because of the type of dash. Not sure how to make a half dash but my guess it was copied from a different font?

Yep. absolutely correct...  THAT is a good catch.

..and a very twisted problem. 

it is the "dash" that is in the "Examples text"...very strange

I don't have my "Hexedit" handy to check the code on that...but whatever it is...it isn't the dash we need!

:-D

Really. nice "Catch" Brandon!

Thanks!

Bob

So...now that CMDlet is working...

This is another odd thing:

Get-PWFolders -FolderID $folderID -JustOne -Slow | Update-PWFolderSecurity ‐MemberType 'ul' ‐MemberName 'MediaWiki' -MemberAccess "fr,fw" -IncludeInheritance -Verbose
Update-PWFolderSecurity : A positional parameter cannot be found that accepts argument 'MediaWiki'.
At line:1 char:52
+ ... One -Slow | Update-PWFolderSecurity ‐MemberType 'ul' ‐MemberName 'Med ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Update-PWFolderSecurity], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,PWPS_DAB.UpdatePWFolderSecurity

** Note: I am setting parameters this way   "‐MemberType 'ul' " and I can't get it to work

THIS does work...relying on position

PS C:\PS> Update-PWFolderSecurity $folder 'ul' 'MDOT Traffic' 'fr', 'fw' -DocumentSecurity -Verbose
VERBOSE: 1 input folder(s).
VERBOSE: MemberType: ul
VERBOSE: Starting Access Control Update Process 4/7/2022 8:23:06 AM.
VERBOSE: MemberName: MDOT Traffic : MemberID: 1530
VERBOSE: Successfully added access control settings for 'Lansing Support\biggarr\SecTest'.
VERBOSE: - Added 'MDOT Traffic' to Document security.
VERBOSE: Ending Access Control Update Process 4/7/2022 8:23:07 AM.
True

Works like a charm...as long as I don't use:  "‐MemberType 'ul' " syntax to set parameters...and rely only on position.

I have not run into this before either...is it a mode or a controllable setting?

I know the parameters have default positioning... but in this case it does not want the "-<param>" flag...it won't even take it

Have you run into this before?

Thanks!

Bob

The member type 'ul' should work fine.

You will need to individually enter the access control settings.  

Don't use: "fr,fw"

Use:  'fr', 'fw'

now that you say that...that one didn't complain...but -MemberName was not happy with me...It's working great...I just have trouble with the parameter specifications...if I rely on positional...it's golden.

 Update-PWFolderSecurity $folder 'ul' 'MDOT Traffic' 'fr', 'fw' -DocumentSecurity -Verbose

Thanks, Brian!

Bob

now that you say that...that one didn't complain...but -MemberName was not happy with me...It's working great...I just have trouble with the parameter specifications...if I rely on positional...it's golden.

 Update-PWFolderSecurity $folder 'ul' 'MDOT Traffic' 'fr', 'fw' -DocumentSecurity -Verbose

Thanks, Brian!

Bob

I almost never rely on positional. I prefer specifying the parameters. Makes everything obvious. Well, unless I'm doing something adhoc.  Anyways, I wrote that cmdlet, so, everything should work with or without specifying the parameters. Not sure why you are encountering so many issues with it.  Take a look at the examples provided.

hahaha! 

It's the "Dash" again  !!!

Get-PWFolders -FolderID $folderID -JustOne -Slow | Update-PWFolderSecurity ‐MemberType 'ul' ‐MemberName 'MediaWiki' -MemberAccess "fr,fw" -IncludeInheritance -Verbose

notice the "dash" in front of the "MemberName" is smaller...shows on the command line as a different color

So.

I copy the Example line to make sure the syntax I start with is correct...this particular text...has those other dashes

Problem solved.

Thank you for your help Guys...that's a new one for me!

Bob

Be sure you are not copying and pasting from Word or another application like that. For some reason the dashes are different.

to be sure...I will be "on guard" :-D

Thanks again, Brian!!

B

I see this when copying pasting from Outlook all the time. Also issues with smart quotes. In fact I've seen this so much I wrote a little function that fixes it for me. It converts smart double quotes to dumb double quotes, smart single quotes to dumb single quotes and both endash and emdash to a normal dash.

I put it in my profile.ps1 so it's always loaded (I also set an alias cc so i don't have to type that long name i came up with)

# Convert some annoying unicode characters into normal versions
function Convert-ClipboardUnicodeEntities {
	$clip = Get-Clipboard -Format Text -Raw -TextFormatType UnicodeText
	if (-not [string]::IsNullOrEmpty($clip)) {
		# replace unicode smart open double quotes with dumb straight double quotes
		$clip=$clip.Replace([char]0x201c,[char]0x0022)
		# replace unicode smart close double quotes with dumb straight double quotes
		$clip=$clip.Replace([char]0x201d,[char]0x0022)
		# replace unicode smart open single quote with dumb straight single quote
		$clip=$clip.Replace([char]0x2018,[char]0x0027)
		# replace unicode smart close single quote with dumb straight single quote
		$clip=$clip.Replace([char]0x2019,[char]0x0027)
		# replace endash with a dash
		$clip=$clip.Replace([char]0x2013,[char]0x002D)
		# replace emdash with a dash
		$clip=$clip.Replace([char]0x2014,[char]0x002D)
		Set-Clipboard -Value $Clip
	}
}

BTW, if you're interested here's a variation on that will convert a projectwise url string that uses html/url entities and turns them into normal strings. I use this copying urls from Outlook that I want to paste into PW Explorer.

# Convert HTML & URL entities to string characters
function Convert-ClipboardHtmlUrlEntities {
	$clip = Get-Clipboard -Format Text -Raw -TextFormatType Text
	if (-not [string]::IsNullOrEmpty($clip)) {
		# URLs can have some weirdly encoded characters, let's fix those
		# clean up URL characters like %20
		$clip=[System.Net.WebUtility]::URLDecode($clip)
		# clean up html entities like <
		$clip=[System.Net.WebUtility]::HTMLDecode($clip)
		# replace &space; with a space (this is not a standard html entity, but ProjectWise uses it)
		$clip=$clip.Replace("&space;"," ")
		Set-Clipboard -Value $Clip
	}
}