Skip to main content

Filesystem Module update 1

Filesystem - Update 1
This is my first update / bug fix for my module Filesystem. The latest release can be downloaded here. For more info on the module see here.


In version 0.91, the following has been changed :


Fixed


In new-fileshare, the path parameter now points to the share path rather than the parent path
Various help file updates


Added


New function : Get-diskspace
New function : Remove-fileshare


Updated


Add-NTFSpermission and remove-NTFSpermission now have a custom option. Any granular permission can be assigned to the file system this way. e.g. The read permission is actually made up of 3 granular permissions, read, listDirectory and ExecuteFile. These can now be assigned individually with Add-NTFSPermission -path d:\data -object adams -Permission custom -custom ListDirectory. The full list of permissions (from .net class [System.Security.AccessControl.FileSystemRights] ) are :


AppendData
ChangePermissions
CreateDirectories
CreateFiles
Delete
DeleteSubdirectoriesAndFiles
ExecuteFile
FullControl
ListDirectory
Modify
Read
ReadAndExecute
ReadAttributes
ReadData
ReadExtendedAttributes
Synchronize
TakeOwnership
Traverse
Write
WriteAttributes
WriteData
WriteExtendedAttributes

cheers

Adam
Labels:

Comments

  1. MikeNovember 3, 2011 at 12:09 AM

    Enable-DFSLinkTarget is not enabling the target. Still disabled. If I run this specifying an enabled target it gets disabled. Disable-EFSLinkTarget works as it should. The enable is the only issue I have run into.

    ReplyDelete
  2. Adam StoneNovember 3, 2011 at 12:26 AM

    Thanks Mike, just updated to 0.93 to fix this and a couple of other bugs

    cheers

    ReplyDelete
  3. David VekemansJanuary 23, 2012 at 2:13 PM

    Hi Adam,

    Great Module. I got a small issue with the new-dfsroot function.
    I'm running the script from a Windows 2008 R2 servers, but our Domain Controllers are still Windows 2003.

    So when you create a new DFS root, the syntax for DFSutil is :
    dfsutil root addDom \\SRV3\DomainNameSpace3 V1 "This is V1 Root"

    I will do the adaptation for myself, but it would be nice if you could add the version of the root as additional parameter for new-DFSroot.

    Thanks,
    David

    ReplyDelete
  4. David VekemansJanuary 23, 2012 at 2:41 PM

    Another comment:
    in the function Add-DFSRoottarget, the share creation line should be:
    $sharecreated = new-FileShare -name $name -server $server -path "$parentpath\$name"

    instead of
    $sharecreated = new-FileShare -name $name -server $server -path $parentpath

    Regards

    ReplyDelete
  5. Adam StoneJanuary 24, 2012 at 3:18 AM

    Thanks David, great feedback! I'll look at adding these to the next release (which hopefully will be in the next couple of weeks)

    cheers

    Adam

    ReplyDelete

Post a Comment

Popular posts from this blog

Enable Powershell Remoting (WinRM) via Group Policy

I have been doing some testing on enabling WinRM via group policy, being that WinRM is the service that Powershell v2 sets up it remoting capabilities. Here are the GPO settings that you need to configure WinRM .... set the winrm service to auto start Computer Configuration \ Policies \ Windows Settings \ Security Settings \ System Services Windows Remote Management (WS-Management)  set Startup Mode to Automatic start the service incorporated in to the above - you may need a restart. create a winrm listener Computer Configuration / Policies / Administrative Templates / Windows Components / Windows Remote Management (WinRM) / WinRM Service / Allow automatic configuration of listeners IPv4 filter: * * is listen on all addresses, or if you only want a particular IP address to respond use an iprange eg 10.1.1.1-10.1.1.254 - don't forget that this IP range has to be valid for all hosts that fall in the scope of the GPO you are creating.  You can use 1...
2 comments
Read more

Assigning Permissions - AGDLP

AGDLP It seems I have been mildly distracted away from the title of this blog site.   It does say AD Admin, but I seem to have been taken away by file system stuff.   I have to say, it has all been worthwhile, but it’s probably time I got back to the real heart of what I do. There are probably a million permission assigning advice pages, but I thought I would put another one out there after referring to AGDLP in my last post. So, what is this all about – AGDLP.   Well, it is something I learned in my MCSE 2003 studies and has become ingrained into my ideals since.   As a contractor, I get to move job often.   This enables me to forge opinions on how to configure things in a domain, and more importantly how NOT to configure things. AGDLP is definitely on the to do list…for anyone in any size domain or forest, as it follows some very basic principals.   I will explain these whilst I go through what AGDPL stands for. A A is for...
2 comments
Read more

Finding out what 'SearchFlags' are set on you AD attributes

Whilst doing some research into indexed attributes, I posted this  a while back on how to find your index attributes.  Since then, I have looked a little deeper into what indexing really means and found this excellent explanation on the numbers that can be found in the searchflags attribute of a schema object. Using Florian’s reference, I built the following script (which is both powershell v1 and v2 compatible) to get the schema attributes from the forest schema and return (among other things) the breakdown of your attributes search flags. $forest = [System.DirectoryServices.ActiveDirectory.forest]::getcurrentforest() $schema = [ADSI]('LDAP://CN=Schema,CN=Configuration,dc=' + ($($forest).name -replace "[.]",",dc=")) $attributes = $schema.psbase.children | where {$_.objectClass -eq "attributeSchema"} $collection = @() foreach ($attr in $attributes){ $store = "" | select "Name","lDAPDisplayName","singlev...
2 comments
Read more