Powershell v3.0 Windows Server 2012
I am trying to use the Grant-NfsSharePermission cmdlet to grant read/write access to all users with local admins having full permissions to a NFS share.
Grant-NfsSharePermission -Name "LABS" -Path "C:\LABS" -ClientName "WIN-TGE0C741D5G" -ClientType "builtin" -Permission readwrite
The error I get is the parameter set cannot be resolved using the specified name parameters. It's in the InvalidArgument category. After looking at the built-in examples, I can't seem to see why this is a problem. I even tried replacing the clientname (which is my machine name) with localhost and 127.0.0.1 and same error.
The Grant-NfsSharePermission cmdlet expects either the name of the NFS share or the path to the share. You provided both and it doesn't like that. Provide either just -Name or just -Path, but not both and it should work.
As TheMadTechnician mentioned in the comments, you can see this by reviewing the online help or built-in help (with Get-Help Grant-NfsSharePermission) and seeing they provide two parameter sets and the examples only show the use of one or the other.
Related
I would like to create a remote folder inside Inbox with this command wit o365 exchange when execute the following command:
New-MailboxFolder -Parent 'username#domain.com:\Inbox\Folder1' -Name 'Folder1.1'
However, this command cannot be used to create folders on other user’s mailbox.
The error is:
The specified mailbox “username#domain.com” doesn’t exist
What's the exactly problem with this command? Anybody know any Workaround? Thanks!
The cmdlet you're trying to use is not supposed to work for mailboxes other than your own (even if you have proper rights). From the documentation:
Use the New-MailboxFolder cmdlet to create folders in your own mailbox. Administrators can't use this cmdlet to create folders in other mailboxes (the cmdlet is available only from the MyBaseOptions user role).
Some possible workarounds are:
Use Create MailFolder from Graph API
Use MFCMAPI (probably not trivial to be automated)
More detailed description can be found here.
I'm working on a script to get my ACLs for all of the shares in my network. I have three separate UNC paths that I am running this on. Two of the three are working perfectly, returning all child items and permissions and such. However, the third UNC path is returning the following error:
Get-ChildItem : Cannot find path '\\storagesrvr' because it does not exist.
I have verified that the location is available by using Explorer. What I find interesting is that if I use GCI on any of the sub-shares of that path, it works. What could possibly be preventing GCI from detecting the root of the share?
EDIT (as requested from comments): The other two shares that I had no issues with were named like \\networkpath\share. But because I was only looking at the root, GCI was not working.
As I mentioned in the comments \\computername is only a partial UNC path (check the UNC grammar in the [MS-DTYP] Windows Data Type specification).
Explorer "knows" this, and so it does some black magic in the background to allow you to browse the shares on the remote computer.
You can emulate this, by querying the Win32_Share WMI instances on the remote machine:
foreach($Share in Get-WmiObject Win32_Share |?{$_.Name -ne 'IPC$'}){
Get-ChildItem "\\$($Share.__SERVER)\$($Share.Name)"
}
You can list shares by calling:
net view \\<computername>
source:
PowerShell Get List Of Folders Shared
The error message is literally correct. \\storageserver is not a path. It is two backslashes followed by a computer name.
Append a share name to it, and it becomes a path; e.g. \\storageserver\sharename.
I want to access this path Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy\Maximum password age in local group policy editor and modify its value through powershell script. I have tried to import module group (Get-Command -Module group*) but no methods/module is found.I have tried the following way in powershell and it didn't work.
Set-ItemProperty -Path \Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy -Name Maximum password age -Value 20
Can someone help me in modifying the value through powershell scripting.
I am new to powershell scripting,so please ignore if any wrong info is
provided.
You can find it in windows registry, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
MaximumPasswordAge REG_DWORD
You can get/set Registry values, somewhat counter-intuitively with the [get/set]-itemproperty commands.
Example:
Get-ItemProperty HKLM:\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\ -Name AllowCredSSP
However, this likely won't reflect in the Local Group Policy Editor interface.
Look up LGPO.exe, documentation is scarce, but it seems to work:
https://blogs.technet.microsoft.com/secguide/2016/01/21/lgpo-exe-local-group-policy-object-utility-v1-0/
(Current download is in the "Security Compliance Toolkit")
https://www.microsoft.com/en-us/download/details.aspx?id=55319
For parameters like max password age, I think best way is to use net.exe commant. Try to execute
net.exe accounts /?
For more complicated group policies in computer without domain, you can prepare policies in one computer, export it to file, and inport in other computers, by using secedit.exe
Try to google secedit /export, secedit /import usage
You can call secedit from powershell without any problems
I'm working on a script to get my ACLs for all of the shares in my network. I have three separate UNC paths that I am running this on. Two of the three are working perfectly, returning all child items and permissions and such. However, the third UNC path is returning the following error:
Get-ChildItem : Cannot find path '\\storagesrvr' because it does not exist.
I have verified that the location is available by using Explorer. What I find interesting is that if I use GCI on any of the sub-shares of that path, it works. What could possibly be preventing GCI from detecting the root of the share?
EDIT (as requested from comments): The other two shares that I had no issues with were named like \\networkpath\share. But because I was only looking at the root, GCI was not working.
As I mentioned in the comments \\computername is only a partial UNC path (check the UNC grammar in the [MS-DTYP] Windows Data Type specification).
Explorer "knows" this, and so it does some black magic in the background to allow you to browse the shares on the remote computer.
You can emulate this, by querying the Win32_Share WMI instances on the remote machine:
foreach($Share in Get-WmiObject Win32_Share |?{$_.Name -ne 'IPC$'}){
Get-ChildItem "\\$($Share.__SERVER)\$($Share.Name)"
}
You can list shares by calling:
net view \\<computername>
source:
PowerShell Get List Of Folders Shared
The error message is literally correct. \\storageserver is not a path. It is two backslashes followed by a computer name.
Append a share name to it, and it becomes a path; e.g. \\storageserver\sharename.
I am trying to copy one file from share in my custom dsc script. This code below works great in powershell, but not working in dsc resource.
PS C:\Users\user> $wc = New-Object System.Net.WebClient
PS C:\Users\user> $wc.DownloadFile("\\DC1\Downloads\en_sql_server_2012_enterprise_edition_with_service_pack_2_x64_dvd_
4685849.iso", "C:\SQL2012SP2.iso")
Powershell 4/5 has native commandlets for get files from smb share? Or any variants?
As #arco444 alluded to, the way you're doing this is bananas. Why not use Copy-Item?
That aside, I think you would have the problem with Copy-Item as well.
DSC runs under the context of SYSTEM, so you should make sure that your share allows access from the machine account of the machine on which the DSC is to be executed.
Alternatively, you can grant read access to Authenticated Users (which includes all other users as well), or Domain Computers if you're in a domain and want all of the computers to be able to read the contents.
The Credential parameter in file resource is used to connect to the source - so you can specify credentials for the share.
However make sure that credentials are secured as described in this article - [link] http://blogs.msdn.com/b/powershell/archive/2014/01/31/want-to-secure-credentials-in-windows-powershell-desired-state-configuration.aspx