Chapter 15. The File System

The file system has special importance within the PowerShell console. One obvious reason is that administrators perform many tasks that involve the file system. Another is that the file system is the prototype of a hierarchically structured information system. In coming chapters, you'll see that PowerShell controls other hierarchical information systems on this basis. You can easily apply what you have learned about drives, directories, and files in PowerShell to other areas, including the registry or Microsoft Exchange.

Topics Covered:

• Table 15.1: Overview of the most important file system commands
• Accessing Files and Directories
  • Listing Directory Contents
  • Recursively Searching the Entire File System
    • Filter and Exclusion Criterion
  • Getting File and Directory Contents
  • Passing Files to Cmdlets, Functions, or Scripts
• Navigating the File System
  • Relative and Absolute Paths
    • Table 15.2: Important special characters used for relative path specifications
    • Converting Relative Paths into Absolute Paths
      • Figure 15.1: Using Resolve-Path to select several files and opening them by querying
  • Saving Directory Locations
  • Finding Special Directories
    • Table 15.3: Important Windows directories that are stored in environment variables
  • Constructing Paths
    • Table 15.4: Methods for constructing paths
• Working with Files and Directories
  • Creating New Directories
  • Creating New Files
  • Creating New Drives
  • Reading the Contents of Text Files
  • Processing Comma-Separated Lists
  • Parsing Text Contents and Extracting Information
  • Reading Binary Contents
  • Moving and Copying Files and Directories
  • Renaming Files and Directories
    • Numerous Renames
    • Changing File Extensions
    • Sorting Out File Names
  • Deleting Files and Directories
    • Deleting Directory Contents
    • Deleting Directories and Their Contents
• Managing Access Permissions
  • Checking Effective Security Settings
    • Establishing the Identity of the Owner
    • Listing Access Permissions
  • Creating New Permissions
    • "Cloning" Permissions
      • Figure 15.2: Modifying security settings of the directory using a dialog box
    • Using SDDL to Set Permissions
    • Manually Creating New Permissions

A number of cmdlets in Table 15.1 do the main work as they are rarely accessed under their real names. Aliases are much more useful and the aliases of cmdlets come from both the Windows and the UNIX worlds. This makes it easy for new learners to find the right cmdlets quickly.

Accessing Files and Directories

Use Get-ChildItem to list the contents of a directory. The predefined aliases for this are Dir and ls. Get-ChildItem perform a number of important tasks:

• Making directory contents visible
• Searching through the file system recursively and finding certain files
• Getting files and directory objects
• Passing files to other cmdlets, functions, or scripts

Listing Directory Contents

In rudimentary cases, you may simply want to know which files are in a certain directory. If you don't specify another one, Dir lists the contents of the current directory. If you specify a directory after Dir, its contents will be listed. Also, if you use the -recurse parameter, Dir will list the contents of all subdirectories. Wildcard characters are also allowed.

For example, if you want to get a list of all PowerShell script files stored in the current directory, type this command:

Dir even accepts arrays, which allow you to list different drives at the same time. The following instruction lists all the PowerShell scripts in the PowerShell root directory, as well as all log files in the Windows directory:

If you're interested only in the names of items in one directory, use the parameter -name. Dir will not retrieve objects (files and directories), but just their names in plain text.

Recursively Searching the Entire File System

Use the -recurse parameter if you want your search to include every subdirectory. However, note the failure of the following invocation:

You need to know a few more details about how -recurse works to understand why this happens,. Dir always retrieves directory contents as file and directory objects. If you set the -recurse switch, Dir will invoke directory objects recursively. Because you instructed Dir in the last example to retrieve only those files that had the .ps1 extension, Dir found no directories that -recurse could have stepped through. The concept may be hard to get used to at first, but it explains why in the following example you get a recursive directory listing, even when you use wildcards:

Here, Dir retrieves all the items from your root directory that begin with the letter "D". The directories are searched recursively as well because directories are among them.

Filter and Exclusion Criterion

But let's return to our initial problem: how to get a recursive listing of all files of one type, such as PowerShell scripts. The answer is to instruct Dir to list the directory contents completely and to specify a filter additionally. Dir then filters the files you want out of all the files:

In addition to -filter, there is a parameter that at first glance works in a very similar way: -include:

You'll see some dramatic speed differences: -filter is much quicker than -include.

The reason is that -include supports regular expressions, which are fundamentally more complicated, while -filter only understands simple wildcard characters. That's why you could use -include to make even more complex filters than the following ones, which find all script files beginning with one of the letters from "A" to "F". That's beyond the capacity of -filter:

The counterpart to -include is -exclude. Use -exclude if you would like to suppress certain files. Unlike -filter, the -include and -exclude parameters accept arrays, which enables you to get a list of all image files in your profile:

Avoid just one thing: don't combine -filter and -include. Choose one of the two parameters. Specifically you should use -filter when you don't need any regular expressions or arrays because of its enormous speed advantage.

Getting File and Directory Contents

You can use Dir to directly access individual files because Dir returns the contents of a directory in the form of file and directory objects. This enables you to obtain the FileInfo object of each file:

This is how you could read the properties of single files as well as modify them if their properties allow modification:

Get-Item uses another approach to access the file object. All three commands return the same result, which is the file object of the specified file.

However, Get-Childitem and Get-Item act very differently when accessing directories instead of files:

Passing Files to Cmdlets, Functions, or Scripts

Because Dir returns individual file and directory objects in its result, Dir can pass these objects directly to other cmdlets or to your own functions and scripts. This makes Dir an important selection command, which you can very conveniently use to recursively find all files having the type you're looking for on the entire hard disk drive or even on several drives.

To do so, process the result of Dir in the pipeline either by using Where-Object and then ForEach-Object (Chapter 5), or write your own pipeline filter (Chapter 9).

Because Dir retrieves directories as well as files, it can sometimes be important to limit the result of Dir only to files or only to directories. There are several ways to do this. You can either validate the attribute of the returned object, the PowerShell PSIsContainer property, or the object type:

The first variant (controlling object types) is the fastest by far while the latter (text comparison) is more complex and slower as a result of it complexity.

Where-Object can filter files according to other criteron as well.

For example, use the following pipeline filter if you'd like to locate only files that were created after May 12, 2007:

You can use relative data if all you want to see are files that have been changed in the last two weeks:

Navigating the File System

Unless you changed your prompt in the way described in Chapter 9, the current directory in which you are working inside the PowerShell console is named at the command line prompt. You can find out what the current directory is by using Get-Location:

If you want to navigate to another location in the file system, use Set-Location or the Cd alias:

Relative and Absolute Paths

Path specifications can be either relative or absolute. In the last example you used both types.

Relative path specifications depend on the current directory, and the .\test.txt specification always refers to the test.txt file in the current directory while ..\test.txt refers to the test.txt file in the parent directory. Relative path specifications are useful, for example, if you want to use library scripts that are located in the same directory as your work script. Your work script will then be able to locate library scripts under relative paths—no matter what the directory is called. Absolute paths are always unique and are independent of your current directory.

Converting Relative Paths into Absolute Paths

Whenever you use relative paths, PowerShell must convert these relative paths into absolute paths. That occurs automatically when you invoke a file or a command using relative paths. You can resolve them yourself by using Resolve-Path.

Resolve-Path, however, only works for files that actually exist. If there is no file in your current directory that's called test.txt, Resolve-Path will report an error.

Resolve-Path can have more than one result if the path that you specify includes wildcard characters. The following invocation will retrieve the names of all the ps1xml files in the PowerShell home directory:

Like Dir, Resolve-Path can act as a selection filter for a downstream function. The following example shows opening a file in Notepad for processing. The command calls Notepad to open a file by using Resolve-Path.

Figure 15.1: Using Resolve-Path to select several files and opening them by querying

If there are no files at all that conform to the criterion, Resolve-Path will throw an error, which will be noted in the $? variable (Chapter 11). The expression !$? is always satisfied when an error occurs, and in such a case the function reports that no file was found.

The result is an array if Resolve-Path finds more than one file. In this case, the function lists the files that were found so not too many files will be unexpectedly opened in the event of a faulty entry. The function uses the internal PowerShell function PromptForChoice() that we saw in Chapter 6 to request the user for confirmation.

The Call operator we saw in Chapter 12 launches the file(s). Of course, this will only work if an application is allocated to the respective file type.

Saving Directory Locations

The current directory where you are working can be "pushed" to the top of a list of locations, called a "stack," by using Push-Location. Each Push-Location adds a new directory to the top of the stack. Use Pop-Location to get it back again.

So, to perform a task that forces you to leave your current directory, first type Push-Location to store your current location. Then, you can complete your task and when ready, use Pop-Location to retrieve your stored location.

Finding Special Directories

Windows uses a number of special directories which, depending on installation, may be found at different locations. The paths of the most important directories are located in the Windows environment variables so that PowerShell can clearly allocate these special directories. You can find many other special directories through the Environment class of the .NET framework.

Environment variables return only a few, and by far not all, of the paths of special directories. For example, if you'd like to put a file directly on a user's Desktop, you'll need the path to the Desktop that the environment variables can't retrieve for you. However, The GetFolderPath() method of the environment class of the .NET framework (Chapter 6) can do that. The following shows how you could put a link on the Desktop.

The types of directories that GetFolderPath() can find are noted in the SpecialFolder enumeration. You should use the following line to view its contents:

If you want an overview of all the directories that GetFolderPath() can locate, you can retrieve that as follows:

Constructing Paths

Path names consist of text so you can construct them however you like. You saw above how you can construct the path of a file that is intended to be on a user's Desktop:

Be absolutely sure that you put the right number of backward slashes in your path. That's why a backward slash was specified in front of the file name in the last example. A more reliable way would be to put together paths using Join-Path or the methods of the Path .NET class:

The Path class includes a number of additionally useful methods that you can use to put together paths or extract information from paths. Just insert [System.IO.Path]:: in front of the methods listed in Table 15.4, for example:

Working with Files and Directories

The cmdlets Get-ChildItem and Get-Item can get you file and directory items that already exist. You can also create your own new files and directories, rename them, fill them with content, copy them, move them, and, of course, delete them.

Creating New Directories

The easiest way to create new directories is to use the Md function, which invokes the cmdlet New-Item internally and specifies as -type parameter the Directory value:

Creating New Files

You could also use New-Item to create new files, but they would be completely empty:

Files are usually automatically created when you save data results because empty files are not particularly useful,. Redirection and the cmdlets Out-File and Set-Content can help you:

As it turns out, redirection and Out-File are very similar in operation: when PowerShell converts pipeline results, file contents look just like they would if you output the information in the console. Set-Content works differently as it only returns directory listing names because when you use Set-Content PowerShell doesn't turn objects into text automatically. Instead, Set-Content takes out a standard property from an object. In this case, the property is Name.

Normally, you would use Set-Content to write any text to a file. This last line shows how you could write a date to a file. For example, if you manually convert the pipeline result by using ConvertTo-HTML, Out-File and Set-Content will behave alike.

You can use either double redirection or Add-Content if you want to attach information to a text file:

The result may surprise you: the double redirection arrow worked, but text was displayed in spaced characters. The redirection operations basically use the console encoding , and this can lead to unexpected results if you happen to mix together the ANSI and Unicode character sets. Instead, use the cmdlets Set-Content, Add-Content, and Out-File without the redirections to avoid this risk. All three commands support the -encoding parameter, which you can use to select a character set.

Creating New Drives

It may surprise you that PowerShell allows you to create new drives. You're not limited to network drives only. You can also use drives as convenient shortcuts to other important locations in your file system and even beyond your file system.

Use New-PSDrive to create new drives. To set up a network drive, proceed as follows:

You can now access the network drive through the new virtual drive network: like this:

It's also easy to create convenient shortcuts in working locations. The next lines create the drives desktop: and docs:, which represent your Desktop and the Windows folder "My Documents":

If you want to change to your Desktop later on, type:

Use Remove-PSDrive to remove a virtual drive you have created. You can't remove the drive if the drive is in use. Note that drive letters for New-PSDrive and Remove-PSDrive are specified without colons. On the other hand, when working with drives using customary file system commands, you do have to specify a colon.

Reading the Contents of Text Files

Use Get-Content to retrieve the contents of a text-based file:

There is a shortcut that uses variable notation if you know the absolute path of the file:

However, this notation usually isn't very practical because it doesn't allow any variables inside braces. In most cases, the file path can't be accessed through the same absolute path on all computer systems.

Get-Content reads the contents of a file line by line and passes on every line of text through the pipeline. So, you should add Select-Object if you wanted to read only the first 10 lines of a very long file:

Use Select-String to filter out the information you want from text files. The next line gets only those lines from the windowsupdate.log file that contain the phrase "added update":

Processing Comma-Separated Lists

You should use Import-Csv if you want to process information from comma-separated lists in PowerShell. For test purposes, first create a comma-separated list:

Now, use Import-Csv to input this comma-separated list:

As you see, Import-Csv understands the comma format and displays the data column by column. Save yourself the substantial effort usually involved in parsing a comma-separated value file: Import-Csv will do it for you. The first line is read as a column heading. You could then conveniently use the data in the comma-separated value as an input, such as to create user accounts.

Parsing Text Contents and Extracting Information

One frequent task is parsing raw data, such as log files , to get a structured readout of all the data. An example of such a log file is the windowsupdate.log file, which keeps a record of all Windows updates details (and which was misused as a guinea pig in previous examples). This file contains numerous data that at first glance seems scarcely readable. Initial analysis shows that the file stores information line by line and separates each piece of data by tab characters.

Regular expressions offer the easiest way to describe such a text format, which you already used in Chapter 13. You could use regular expressions to correctly describe the windowsupdate.log file contents as follows:

$matches returns a hit here for every expression in parentheses so you could address each text array on every line through the index numbers. For example, if you are only interested in the date and the description in a line y, then format it as follows:

Here, it is recommended that you give every subexpression its own name, which you can use later to query the result:

You could now read in the entire log file, line by line, by using Get-Content, and then parse every line just the way it was above. This means that you could collect all the information you need, even from a gigantic log file, quickly and relatively efficiently. The next example does exactly that by listing only those lines in whose description is the phrase "woken up". This helps you find out whether a computer was woken up from the standby or sleep mode by automatic updates:

If the loop is successful, it will output the entire line that was stored in $­_. You now know how you could use a further regular expression to split up this line into arrays to output from it only certain pieces of information.

However, there is a second, and a much more sophisticated, way to select individual text lines of the file: Switch. Merely tell this statement which file you want to examine and how the pattern looks that you're looking for. Switch will do the rest. The next statement gets all log entries showing installed automatic updates, and it does so considerably faster than if you had used Get-Content and ForEach-Object. Just remember that in regular expressions ".*" can represent any number of any characters.

Just substitute "SMS" or "Defender" for "automatic updates" in your regular expression if you'd like to find out when other updating programs, such as SMS or Defender, have installed updates. In fact, Switch can look for more than one pattern, and depending on the pattern it finds, carry out the instructions in the braces that follow it. This means you need only a few lines of code to find out how many updates you received and from which service:

Reading Binary Contents

Not all files contain text. Sometimes, it's necessary to read information from binary files. Normally, the visible file extension of a file plays the greatest role because it determines which program Windows uses to open the file. However, in many binary files, a header is also tightly integrated with the file. The header includes an internal type designation that provides information about what sort of file it is. Get-Content can obtain these "magic bytes" with the help of the parameters -readCount and -totalCount. The parameter -readCount indicates how many bytes are read in one step; -totalCount determines the number of bytes that you want to read from the file. In this case, the bytes you're looking for are the first four bytes of the file:

The first four bytes of the Explorer are 4d, 5a, 90, and 00—or are given as the text MZ. Those are the initials of Mark Zbikowski, one of the developers of Microsoft DOS. The tag MZ represents executable programs. The tag looks different for graphics:

Moving and Copying Files and Directories

Move-Item and Copy-Item perform moving and copying operations. You may use wildcard characters with them. The following statement copies all PowerShell scripts from your home directory to the Desktop:

However, only those scripts were copied that are directly available in the $home directory. While Copy-Item is familiar with the -recurse parameter, the parameter, similar to Dir, won't work if your initial path no longer contains any directories.

Use Dir to copy all the PowerShell scripts to your Desktop anyway. Let it find the PowerShell scripts for you, and then pass the result on to Copy-Item:

Because by now your Desktop is probably teeming with PowerShell scripts, it would be better to store them in their own subdirectory. You should create a new subdirectory on the Desktop, and move all your PowerShell scripts on the Desktop into this subdirectory:

Your Desktop is now tidy again, and all your scripts are safely stored in a common directory on your Desktop.

Renaming Files and Directories

Use Rename-Item if you want to give a file or a directory another name. But be careful when you do this because Windows could be ruined if you rename system directories or files. Even if you rename the file extensions of files, you may not be able to open these files and display them properly any more.

Numerous Renames

Because Rename-Item can be used as a building block in the pipeline, it provides surprisingly simple solutions to complex tasks. For example, if you want to remove the term "x86" from a directory and all its subdirectories, as well as all the included files, this instruction will suffice:

However, this command will now actually attempt to rename all the files and directories, even if the term you're looking for isn't even in the file name. That generates errors and is very time-consuming. To greatly speed things up, sort out in advance all the files and directories that are in question by using Where-Object, which can increase speed by a factor of 50:

Changing File Extensions

If you want to change the file extension, be aware first of the consequences: the file will subsequently be recognized as another file type, and possibly be opened by the wrong application program or perhaps not be able to be opened by any application at all. The next instruction renames all PowerShell scripts in the current directory and changes the file extension from ".ps1" to ".bak".

Because of the -whatIf parameter, initially the statement only indicates which renaming operation you could carry out.

Sorting Out File Names

Data collections often grow over time. If you want to sort out a directory, you could give all the files it contains uniform names and sequential numbers, or you could synthesize file names from some specific properties of files. Remember that PowerShell script folder that we just created on your Desktop? Let's properly number the PowerShell scripts in the folder in sequence:

Deleting Files and Directories

Use Remove-Item or the Del alias to remove files and directories, which deletes files and directories irrevocably. If a file is write-protected, you'll have to specify the -force parameter.

Deleting Directory Contents

Use wildcard characters if all you want to do is to delete the contents of a directory, but still keep the directory. The following line, for example, will delete the contents of the Recent directory, which corresponds to "My Recent Documents" on the start menu. Because deleting files and directories is not something to be taken lightly and can have serious consequences, you can just simulate their deletion first by using -whatIf to see what happens:

If you are convinced that your command is correct, and that it will delete the correct files, repeat the statement without -whatIf. On the other hand, if you're still unsure, you can also use -confirm, which makes every deletion contingent on your approval.

Deleting Directories and Their Contents

If a directory is deleted, its entire contents will be lost. PowerShell requests confirmation whenever you attempt to erase a directory along with its contents to prevent you from unintentionally destroying large quantities of data. Only the deletion of empty directories does not require confirmation:

But if you had specified the -recurse parameter, PowerShell would have deleted the directory, including its contents, immediately and without asking for confirmation:

Managing Access Permissions

For NTFS drives, access permissions determine which users may access files and directories. For each file and directory, security data is laid down in what is known as a "security descriptor" (SD). The security descriptor determines whether security settings are valid only for the current directory or whether they can be passed on other files and directories. The real access permissions are on access control lists (ACL). An access control entry (ACE) for every single access permission is on the ACL.

PowerShell uses the cmdlets Get-Acl und Set-Acl to manage permissions. In addition, traditionally proven commands like cacls are available to you in the PowerShell console. Often, they can modify access permissions more quickly than PowerShell cmdlets, particularly when you're working with very many files and directories. Since Windows Vista was released, cacls has been regarded as outdated. If possible, use its successor, icacls.

Checking Effective Security Settings

Effective security settings of directories and files are on the access control list, and PowerShell retrieves the contents of this list when you use Get-Acl. So, if you would like to find out who has access to a certain file or a certain directory, proceed as follows:

Establishing the Identity of the Owner

The owner of a file or directory has special rights. For example, the owner can always get access and you can find the owner in the Owner property:

Listing Access Permissions

Actual access permissions—who may do what—are output in the Access property:

The IdentityReference column of this overview tells you who has special permission; the FileSystemRights column also tell you the type of permission. The AccessControlType column is particularly important because if it shows Deny instead of Allow, you will know who is restricted and who has access.

Creating New Permissions

The object returned by Get-Acl contains a number of methods that you can use to modify permissions or assume ownership. If you'd like to set permissions yourself, you don't necessarily have to delve deeply into the world of security descriptors. Often, it suffices either to read the security descriptor of an existing file and to transfer it to another or to specify the security information in the form of a text in the special SDDL language.

Whether you want to modify the structure of the security descriptor yourself or acquire a complete security descriptor: use Set-Acl to assign the security descriptor to a new object.

"Cloning" Permissions

In a rudimentary case, you wouldn't create any new permissions but would "clone" permissions by transferring the access control list of an existing directory (or a file) to another. The advantage is that this enables you to use a graphic interface to set permissions, which are often complex.

To begin, create two directories as a test:

Now, open Explorer, and change the security settings of the Prototype directory.

In Explorer, right-click the Prototype directory and select Properties. Then, click the Security tab.

Figure 15.2: Modifying security settings of the directory using a dialog box

Click Modify and add additional people to change the security settings of the test directory. Set permissions for the new persons in the lower area of the dialog box.

After you've changed permissions, take a look at the permissions of the second test directory, Protected, in Explorer. This directory is still assigned default permissions. In the next step, the new permissions of the Prototype directory will be transferred to the Protected directory:

That's all there is to it. The Protected directory is now just as secure as the Prototype directory, and when you check their security settings in Explorer, you'll see that all their settings are identical.

Using SDDL to Set Permissions

The previous example was very simple because all you did was transfer the security settings of an existing directory to another. In your daily work, you'll always require a Prototype directory, and that's often unwanted. But you can also summarize the security settings of a security descriptor as text. Each security setting is defined in the special Security Descriptor Description Language (SDDL). It enables you to read out the security information of the Prototype directory as text and use it later without having to resort to the Prototype directory.

Let's delete the old Protected test directory, and then save the security information of the Prototype directory in the SDDL:

You could now include the SDDL text in a second script and assign its security settings to any directory .

Manually Creating New Permissions

Permissions can also be created manually. The advantage is that you specify authorized users by name so that this approach would work on any computer in the same way—even if there is no central domain.

But note that this involves extra effort because then you would have to create the security descriptor entirely on your own. The next example will show you how to do this. However in practice, this procedure is usually too time-consuming. It's simpler in this case to use commands like cacls or icacls. Now, let's delete the Protected test directory again and create a new one so that the directory is again assigned default access rights:

Ultimately, this directory should have general read access permission for the Everyone group and full access to the Administrator account. To accomplish this, use AddAccessRule() to add two new access rules to the security descriptor:

Next, let's look at how each access rule is defined. Five details are required for each rule:

• Person: Here the person or the group is specified to which the rule is supposed to apply.
• Access: Here permissions are selected that the rule controls.
• Inheritance: Here the objects are selected to which the rule applies.The rule can, and normally also is, granted to child objects, so it applies automatically to files that are in a directory.
• Propagation: Determines whether permissions are passed to child objects (such as subdirectories and files). Normally, the setting is None and permissions are merely granted.
• Type: This enables you to set either a permission or restriction. If restriction, the permissions that were specified will expressly not be granted.

The next question is: which values are allowed for these specifications? The example shows that specifications are given in the form of special .NET objects (Chapter 6). You can list all the permitted values for access permissions by using the following trick:

You would actually have to combine the relevant values from the list if you want to set access permissions, such as like this:

The result is a number, the bitmask for permissions to read and write. In the above example, you achieved the same result more easily because you are allowed to specify wanted items, even if they are comma-separated items and enclosed in brackets, after a .NET enumeration:

Because you didn't carry out any binary -bor calculations here, the result is readable text. But in this case the bitmask is at work here, as the conversion to the Integer data type proves. You can find out what the underlying value of a setting is at any time like this:

The significance of this for you is that you can now examine the permitted values for the other .NET enumerations and convert these into numbers. While it won't make your commands more readable, they will be shorter because the following lines do the same thing as the lines in the preceding example:

Finally, let's look at how PowerShell specifies persons to whom permissions apply. In the above examples, you specified the names of users or of groups. Because permissions are not responsive to names, but to the unique SIDs of user accounts, names are changed internally to SIDs. You can also change names manually to see whether a specified user account in fact exists:

An NTAccount object describes a security principal, which is something to which permissions can be granted. In practice, this is users and groups. The NTAccount object can use Translate() to output the information it contains through the principal into its SID. However, this will only work if the specified account in fact exists. Otherwise, you will get an error, so you should use Translate() to validate the existence of the account.

The unique SID that Translate() retrieves is also useful. If you look closely, you'll discover that the SID of the Administrators group clearly differs from the SID of your own user account:

The SID of the Administrators group is not only much shorter, but also unique. For its integrated accounts, Windows uses so-called "well-known" SIDs, which are the same in all Windows systems. This is important because if you were to run your above script on a German system, it would fail since the Administrators group is called "Administratoren," and the "Everyone" group is called "Jeder" on systems localized for Germany. The SIDs of these groups are identical, and knowing this for integrated accounts, you should use SIDs instead of localized names. This is how you turn a SID into the name of a user account:

And this is how your script could work flawlessly in international localizations: