Search This Blog

Showing posts with label Windows. Show all posts
Showing posts with label Windows. Show all posts

Thursday, October 3, 2013

Remote Network Access: Objectives and Architecture

In the this mini-series of posts, I am going to diverge from my usual System Center-only focus to take a fresh look at deploying a Microsoft Remote Network Access solution. First, we'll get you online and working using SSTP, and then extend this base implementation with Network Access protection before finally coming back a little later and elevating these SSTP servers to Direct Access.

Why Remote Network Access?

So why I am doing this? As we build out solutions for System Center, we need a foundation from which to work, and within the latest versions of Configuration Manager we have the ability to integrate with the Windows Network Access Protection and manage our off-site computers with a dial out approach over Direct Access. Also, in the new R2 releases we can integrate both our Certificate Servers (Certificate Authority – CAs) and we finally have the ability to distribute VPN Profiles to our end users. Therefore, I am considering this miniseries as a foundation for illustrating these features and abilities in later posts.
I am building this solution out using the recently published RTM builds of Windows Server 2012 R2, but almost everything I will cover in this series will work from 2008 R2, with some minor adjustments and wizard changes.

Architecture

The environment which we will use for the scenarios is illustrated in the graphic below, showing our client establishing a connection with the RRAS server over TCP443 or what you might better recognize as the HTTPS port. SSTP utilizes this same supporting environment, including the SSL certificates used to protect the tunnel.
I have tagged a number of the components with a  to indicate the initial systems which are engaged in the basic SSTP implementation, including the Network Policy Server (otherwise known as RADIUS), which is used to check the client's authorization to proceed with establishing the requested tunnel.
The remaining servers are added to the scenario as we enable the NAP services, including the Certification Authority, and as an example, a simple Windows Update Server to offer simple remediation to non-compliant clients.

Each of the servers are responsible for different roles in the overall solution. To get a brief understanding of what these are, let's take a quick look at their primary functions.
  • NPS Server – This hosts the Network Policy Services and Network Access Protection services. This server can also be referred to as the Radius Server. When we extend the solution with support for Network Access Protection, we will add a second role to this server called Health Replication Authority (HRA), which will connect to our Certificate Server to request and Issue health certificates
  • SSTP Server – This server hosts the actual Routing and Remote access installation. It will be configured to primarily offer SSTP-only tunnels, and it will connect to the NPS server for authentication and accounting (storing auditing) information, with the purpose of determining if the clients are indeed permitted to establish the tunnels
  • CA Servers  These host PKI certificate templates and issues certificates based on these templates to our systems. It is also responsible for issuing the Health Certificates via the Health Responsibility Authority. We will need to actually create the templates for these Health Certificates as part of the deployment.
  • Client Computers – These are domain-joined machines that will subscribe to the new SSTP service that we are implementing. SSTP is supported from Windows 7 and newer versions of the client. Non-domain-joined machines can of course work with SSTP, but for the scope of this mini-series I am focusing on domain-joined systems.

We now have the background and an idea of how the different servers will be used. Our next objective will be to implement this solution. Now would be a great time to get your environment ready and spin up some servers for the jobs we are about to face.

How to back up the registry in server

How to step by step back up of registry in server 2008, if you are editing in windows registry make sure you have backup of registry. If any problem occurs you can safely restore your registry. You can backup Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 by this method. Before create a backup you should login with administrator.

Follow these steps to backup registry:-

 1.      Click Start, and then click Run.

 2.      In the Open box, type "regedt32", and then click ok.


 3.      On the Registry menu, click Export.

 
4.      In the Save inbox, select a location in which to save the .reg file, type a file name in the File name box, and then click Save.

Tuesday, October 1, 2013

How to change the listening port for Remote Desktop

Remote desktop listening port 3389 is working by default in server 2008. You can change and define custom listening port for remote desktop. You can define port number between 1025 and 65535.

How to change the Remote Desktop listening port on Windows Server 2008?

You can change remote desktop listening port on server 2003, windows xp and windows 7 by same method.


  1. Click on Start and type “regedit” or you can press windows key + R to lunch run and type “regedit”  and press enter  Registry Editor will open.
 
  1. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
  1. Select PortNumber and double click on it then click Decimal.
  2. Find the "PortNumber" subkey and notice the value of 00000D3D, hex for (3389)
  3. Type the new port number, and then click OK.
  4. Quit Registry Editor.
  5. Restart the computer.
Now you can check form other computer start Remote Desktop Connection form start -> all programs -> accessories -> remote desktop connection.

Now type ip address with port of server (IP address:Custom port).


Troubleshooting 

Note When you try to connect to this computer by using the Remote Desktop connection, you must type the new port. Maybe you have to set the firewall to allow the new port number before you connect to this computer by using the Remote Desktop connection.


If you got this message “The remote computer requires Network Level Authentication, which your computer does not support. For assistance, contact your system administrator or technical support”

Friday, September 27, 2013

Daily Technotips: How to Implement Group Policy Security Filtering?

The most misleading thing about Group Policy is its name—Group Policy is simply not a way of applying policies to groups! Instead, Group Policy is applied to individual user accounts and computer accounts by linking Group Policy Objects (GPOs), which are collections of policy settings, to Active Directory containers (usually OUs but also domains and sites) where these user and computer accounts reside. So the newbie’s question concerning Group Policy is usually, “How can I get this GPO to apply to this group?” The answer to this question is: by implementing security filtering.

Understanding Security Filtering

Security filtering is based on the fact that GPOs have access control lists (ACLs) associated with them. These ACLs contain a series of ACEs for different security principals (user accounts, computer accounts, security groups and built-in special identities), and you can view the default ACL on a typical GPO as follows:
  1. Open the Group Policy Management Console (GPMC)
  2. Expand the console tree until you see the Group Policy Objects node.
  3. Select a particular GPO under the Group Policy Objects node.
  4. Select the Delegation tab in the right-hand pane (see Figure 1).

Figure 1: Viewing the ACL for the Vancouver GPO using the Delegation tab
For a more detailed view of the ACEs in this GPO ACL, click the Advanced button to display the familiar ACL Editor (Figure 2):

Figure 2: Viewing the ACL for the Vancouver GPO using the ACL Editor
An obvious difference between these two views is that the ACL Editor displays the Apply Group Policy permission while the Delegation tab doesn’t. This is because the Delegation tab only displays ACEs for security principles that actually process the GPO, and that implicitly means those security principals have the Apply Group Policy permission set to Allow. More specifically, if you want a GPO to be processed by a security principal in a container linked to the GPO, the security principal requires at a minimum the following permissions:
  • Allow Read
  • Allow Apply Group Policy
The actual details of the default ACEs for a newly created GPO are somewhat complex if you include advanced permissions, but here are the essentials as far as security filtering is concerned:
Security PrincipalReadApply Group Policy
Authenticated UsersAllowAllow
CREATOR OWNERAllow (implicit)
Domain AdminsAllow
Enterprise AdminsAllow
ENTERPRISE DOMAIN CONTROLLERSAllow
SYSTEMAllow
Note that Domain Admins, Enterprise Admins and the SYSTEM built-in identity have additional permissions (Write, Create, Delete) that let these users create and manage the GPO. But since these additional permissions are not relevant as far as security filtering is concerned, we’ll ignore them for now.
The fact that Authenticated Users have both Read and Apply Group Policy permission means that the settings in the GPO are applied to them when the GPO is processed, that is, if they reside in a container to which the GPO is linked. But who exactly are Authenticated Users? The membership of this special identity is all security principals that have been authenticated by Active Directory. In other words, Authenticated Users includes all domain user accounts and computer accounts that have been authenticated by a domain controller on the network. So what this means is that by default the settings in a GPO apply to all user and computer accounts residing in the container linked to the GPO.

Using Security Filtering

Let’s now look at a simple scenario where you might use security filtering to resolve an issue in Group Policy design. Figure 3 below shows an OU structure I developed in a previous article. Note that the Vancouver top-level OU has three departments under it defined as second-level OUs, with user and computer accounts stored below these departments in third-level OUs:

Figure 3: Sample OU structure for Vancouver office
Let’s say that of the fifteen users who work in the Sales and Marketing Department in Vancouver, three of them are senior people who have special requirements, for example access to certain software that other people in the department shouldn’t have access to. Such software could be provided to them by publishing it in Add or Remove Programs using a user policy-based software installation GPO. The trouble is, if you link this GPO to the Sales and Marketing Users OU then all fifteen users in the department will have access to it through Add or Remove Programs. But you only want this special group of three users to be able to access the software, so what do you do? 
You could create another OU beneath the Sales and Marketing Users OU and call this new OU the Senior Sales and Marketing Users OU. Then you could move the user accounts for the three senior employees to this new OU and create your software installation GPO and link it to the new OU. While this approach will work, it has several disadvantages:
  • It makes your OU structure deeper and more complicated, making it harder to understand.
  • It disperses user accounts into more containers making them more difficult to manage.
A better solution is to leave your existing OU structure intact and all fifteen Sales and Marketing users in the Sales and Marketing Users OU, create your software installation GPO and link it to the Sales and Marketing Users OU (see Figure 4), and then use security filtering to configure the ACL on the software installation GPO to ensure that only the three senior users receive the policy.

Figure 4: Senior Sales and Marketing Users Software Installation GPO
To filter the software installation GPO so that only users Bob Smith, Mary Jones, and Tom Lee receive it during policy processing, let’s first use Active Directory Users and Computers to create a global group called Senior Sales and Marketing Users that has only these three users as members (see Figure 5):

Figure 5: Membership of the Senior Sales and Marketing Users global group
Note that you can store this security group in any container in the domain, but for simplicity you’ll probably want to store it in the Sales and Marketing Users GPO since that’s where its members reside.
Now go back to the GPMC with the software installation GPO selected in the left-hand pane, and on the Scope tab of the right-hand pane, remove the Authenticated Users special identity from the Security Filtering section and then add the Senior Sales and Marketing Users global group (Figure 6):

Figure 6: Filtering the GPO so it only targets the Senior Sales and Marketing Users group
That’s it, we’re done! Now when policy is processed for a user account residing in the Sales and Marketing Users OU, the Group Policy engine on the client will first determine which GPOs need to be applied to the user. If the user is a member of the Senior Sales and Marketing Users security group, the following GPOs will be applied in the following order (assuming we haven’t used blocking or enforcement anywhere):
  1. Default Domain Policy
  2. Vancouver GPO
  3. Sales and Marketing GPO
  4. Sales and Marketing Users GPO
  5. Senior Sales and Marketing Users GPO

The Power of Security Filtering

The power of security filtering is that it allows us to simplify our OU structure while still ensuring that Group Policy is processed as designed. For example, in my original OU structure for Vancouver (see Figure 3 above) I created separate OUs for three departments in that location, namely the IT Department, Management, and Sales and Marketing. In Toronto however I could have taken a different approach and lump all my users and computers together like this (Figure 7):

Figure 7: Toronto has a simpler OU structure than Vancouver
Then I could group user and computer accounts in Toronto into global groups like this:
  • IT Department Users
  • IT Department Computers
  • Management Users
  • Management Computers
  • Sales and Marketing Users
  • Sales and Marketing Computers
I could then create GPOs for each group of users and computers in Toronto, link these GPOs to the appropriate container, and use security filtering to ensure they are applied only to the desired security principals (Figure 8):

Figure 8: Using Group Policy to manage users in Toronto
The main downside of this approach is that as you flatten your OU structure you can end up with lots of GPOs linked to each OU, which can make it harder at first glance to figure out which policies are processed by each user or computer unless you examine in detail the security filtering setup

Sunday, April 28, 2013

Laptop taking too much time to Shutdown

Laptop taking too much time to shutdown?

We have observed that some of the laptops takes more than 5 minutes to close all the applications and shutdown. To reduce this process time follow the instructions below:

1. Click on Start button, select Run, type Regedit and press Enter.
2. Expand: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
3. Edit the value data of Wait to kill service timeout to 1500

This will improve the performance of Shutdown!!


Thursday, April 25, 2013

Resetting Windows Password using Hiren Boot CD


Tested on: NT 3.51, NT 4 (all versions and SPs), Windows 2000 (all versions & SPs), Windows XP (all versions, also SP2 and SP3), Windows Server 2003 (all SPs), Windows Vista 32 and 64 bit (SP1 also), Window 7 (all variants). Some also say that it works on Windows Server 2008 too.
If used on users that have EFS encrypted files, and the system is XP or Vista, all encrypted files for that user will be UNREADABLE! and cannot be recovered unless you remember the old password again. If you don’t know if you have encrypted files or not, you most likely don’t have them (except maybe on corporate systems).
Boot your computer with Hiren’s BootCD and follow the steps below for resetting your password:

1. Enter “Offline NT/2000/XP/Vista/7 Password Changer”

With Up & Down keys select Offline ‘NT/2000/XP/Vista/7 Password Changer’ and press Enter.



2. Wait for “Offline NT Password & Registry Editor” to Load

On the screen below, you’ll see is several lines of text that quickly run down the screen. You don’t need to do anything here. Wait for “Offline NT Password & Registry Editor” to load.



3. Choose the Correct Hard Drive Partition

This step in the Offline NT Password & Registry Editor process is to select the partition that contains the Windows installation that you want to delete a password from.
Many computers have a single operating system installed on a single partition on a single hard drive, making this a very easy choice.
If that’s the case for you, just press ENTER to accept the default partition. Otherwise, type the number corresponding to the correct partition from the Candidate Windows partitions found list and then press ENTER.
If more than one partition is listed and you’re not sure which one to pick, chances are the larger partition is the one with Windows installed.
Every Windows 7 PC will have more than one partition listed.


4. Confirm the Windows Registry Path

Offline NT Password & Registry Editor now needs to know the exact location of the Windows Registry. Except in the rarest of occasions, the default location will be the correct one.
Just Press ENTER to accept the default Windows Registry path without writing anything else.


5. Choose the Password Reset Option

Offline NT Password & Registry Editor is now asking which part of the registry it should load.
Press ENTER to accept the default choice of Password reset.
The Offline NT Password & Registry Editor tool can perform various functions aside from resetting passwords but since that’s the focus of this particular walkthrough, that’s all we’ll discuss.


6. Choose the Edit User Data and Passwords Option

Now that the registry is loaded and available to the program, Offline NT Password & Registry Editor needs to know exactly what you want to do.
Press ENTER to accept the default choice of Edit user data and passwords.
This will load the necessary options for the actual password reset.



7. Enter the Username to Edit

Offline NT Password & Registry Editor now needs to know which user’s password you’d like to delete (erase, clear, blank, remove, call it what you like).
A default user is listed between the brackets at the prompt. In the above example, you can see that it’s the Administrator user.
If the default user is the user you’d like to remove the password from, simply press ENTER. Otherwise, enter the username and then press ENTER.



8. Type 1 to Clear (blank) user password and then press ENTER

At the bottom of the screen you’ll see the User Edit Menu with several options to choose from.
Type 1 for Clear (blank) user password and then press ENTER.
Offline NT Password & Registry Editor shows some interesting information about the username you entered in the last step – the full name, what groups the user belongs to, how many failed login attempts have taken place, how many total logins have been completed, and more.
If you see a check in the “Passwd not req.” box, this means that a password is not a requirement for this particular user. It does not mean that a password is not required to access the account in Windows. In other words, it’s saying that it is possible to erase this user’s password.


9. Type ! to quit the User Edit Tool

Assuming there weren’t any problems, you should see a Password cleared! message after entering 1 in the previous step.
Type ! to quit editing user and then press ENTER.
You must confirm these changes in a later step before they are actually complete. If you quit Offline NT Password & Registry Editor now then the password reset will not take place!


10. Type q to Quit Offline NT Password & Registry Editor

Enter q and then press ENTER to quit the Offline NT Password & Registry Editor registry editing tool.
Important: You’re still not done! You need to confirm your password reset change in the next step before it will take effect.

11. Type y and then press ENTER to confirm Password Reset Changes

At the Step FOUR: Writing back changes menu, Offline NT Password & Registry Editor asks if you want to write file(s) back.
Type y and then press ENTER.
You should see an EDIT COMPLETE message appear on screen. If you do, it means that Offline NT Password & Registry Editor has written the password changes to your computer!


12. Confirm That You’re Finished Using Offline NT Password & Registry Editor

Offline NT Password & Registry Editor gives you an option here to rerun the program. If you’ve been following along with this guide and everything seems to have worked properly then there’s little reason to repeat anything.
Press ENTER to confirm the default option of not rerunning the password reset.



13. Remove Hiren’s BootCD and Restart the Computer

That’s it! You’ve just completed the entire Offline NT Password & Registry Editor password removal process.

Remove Hiren’s BootCD from your CD/DVD drive and then manually reset your computer.Note: If you receive a “job control turned off” or a “can’t access tty” error, don’t worry. As long as the EDIT COMPLETE confirmation message was posted to the screen after you confirmed the password reset changes then your password was successfully reset. You should still be able to see the confirmation on the screen at this point.
In the next step, you’ll finally get to logon to Windows without entering a password!
Now that your password has been removed using Offline NT Password & Registry Editor, no password is required to log on to Windows.
If you are the only user on your computer, Windows will boot all the way to the desktop on the next reboot and will skip the logon screen altogether.
If you’re on a multi-user computer (as many families are), the logon screen will still appear after starting Windows but when you click on the user that had the password removed, you will not be prompted for a password and will instead enter Windows automatically.
Having a secure password is important so please don’t continue to use Windows without one. As soon as you’ve gained access to your computer again, configure a new password – one you can remember a little easier!

There is a video link to help you:




How To Disable AutoRun / AutoPlay In Windows 7 & Windows 8


Disable AutoRun / AutoPlay Using Local Group Policy Editor
Step 1: Pull up the Run dialog box (Win + R) and type gpedit.msc. Hit Enter to launch the Local Group Policy Editor.
Step 2: Within Group Policy Editor, navigate to this location:
Computer Configuration > Administrative Templates > Windows Components > AutoPlay Policies
AutoRun
Step 3: Double-click the Turn off Autoplay option to edit its settings, select Enabled, and then select All drives in the options panel below. Hit Apply when done.
Disable-AutoRun
Step 4: Restart your computer.
That’s it; the AutoRun feature has been completely disabled for all users, and for all drives that connect to your machine.
Disable AutoRun / AutoPlay Using Registry Editor
Should you have a version of Windows that doesn’t ship with Local Group Policy Editor, follow these instructions.
Step 1: In the Run dialog, type regedit to launch the Registry Editor.
Step 2: Depending on whether you want to disable AutoRun for all users or just for the current one, navigate to either of these registry keys (the first one is for all users):
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\policies\Explorer\
Step 3: Within this subkey, locate the setting labeled “NoDriveTypeAutoRun”. If it doesn’t exist, create a new 32-bit DWORD with this name and assign it the hexadecimal value 000000FF(Decimal 255).
RegEdit-Disable-AutoRun
The DWORD defined above will disable AutoRun for all drives and devices, and will have the same effect that you would’ve gotten through Local Group Policy Editor.
Should you want to restore AutoPlay ever again, just reverse the changes that you made in these steps, and you should be good to go.

I am sharing this tech update from :

Monday, September 24, 2012

Wipe your Deleted Data Away: Using cipher.exe

Administrators can use Cipher.exe to encrypt and decrypt data on drives that use the NTFS file system and to view the encryption status of files and folders from a command prompt. An updated version of the Cipher tool has been released for Windows 2000, and is included with Windows XP. The updated version adds another security option. This new option is the ability to overwrite data that you have deleted so that it cannot be recovered and accessed.

When you delete files or folders, the data is not initially removed from the hard disk. Instead, the space on the disk that was occupied by the deleted data is "deallocated." After it is deallocated, the space is available for use when new data is written to the disk. Until the space is overwritten, it is possible to recover the deleted data by using a low-level disk editor or data-recovery software.

If you create files in plain text and then encrypt them, Encrypting File System (EFS) makes a backup copy of the file so that, if an error occurs during the encryption process, the data is not lost. After the encryption is complete, the backup copy is deleted. As with other deleted files, the data is not completely removed until it has been overwritten. The new version of the Cipher utility is designed to prevent unauthorized recovery of such data.

Most Windows 2000 and XP Professional users are aware of the ability to encrypt data at the file level, using the Encrypting File System (EFS). It’s easy to do through the graphical interface—as easy as checking a checkbox on the Advanced File Attributes property sheet. However, many IT pros aren’t aware that encryption can also be performed at the command line.

The cipher.exe utility is included with Microsoft’s most recent NT-based operating systems. It allows you to do the same tasks—encrypt and decrypt—that you can do through the GUI, but also allows you to do much more—all through the command line. Administrators and power users can take advantage of the cipher tool’s power to gather encryption information and more quickly perform encryption tasks.

This Daily Drill Down will introduce you to the cipher tool and walk you through the steps of using its various switches.

Why a command line encryption tool?
What’s the need for a command line encryption tool if it’s so easy to encrypt and decrypt files using the GUI (other than the fact that some of us just like the character-based interface)? While encryption and decryption are easy attributes to set through a file or folder’s property sheet, there are other encryption-related tasks that are difficult (or impossible) to accomplish through the GUI.

For example, what if a user wants to create a new file encryption key? You might think you could generate a new key pair by requesting a new EFS certificate. You would do this by invoking the Certificate Request Wizard via the Certificates MMC (if you’re in an Active Directory domain) or via the certification authority’s Web page. But the problem with this method is that the file encryption key that is generated by EFS is wrapped with the user’s public key during the encryption process. As a workaround, the cipher tool allows you to create a new encryption key by typing cipher /k.

What if you want to encrypt files that are already encrypted? There’s no way to do that through the graphical interface; you must first decrypt the file before you’re allowed to change its attribute back to encrypted. With the cipher tool, you can force encryption on all files and folders, including those that are already encrypted.





Tip
The original version of cipher.exe that was released with Windows 2000 does not include the data overwrite function. This was added in a version of the cipher tool that Microsoft released in June 2001 (and included in Windows 2000 SP3). The drive-wiping function is included in the cipher tool that comes with Windows XP.




The cipher.exe command is an external command that is available in the below Microsoft operating systems.
Syntax
Displays or alters the encryption of directories [files] on NTFS partitions.
CIPHER [/E | /D] [/S:dir] [/A] [/I] [/F] [/Q] [/H] [/K] [pathname [...]]
CIPHER /W:directory
CIPHER /X[:efsfile] [filename]
/EEncrypts the specified directories. Directories will be marked so that files added afterward will be encrypted.
/DDecrypts the specified directories. Directories will be marked so that files added afterward will not be encrypted.
/SPerforms the specified operation on directories in the given directory and all subdirectories.
/AOperation for files as well as directories. The encrypted file could become decrypted when it is modified if the parent directory is not encrypted. It is recommended that you encrypt the file and the parent directory.
/IContinues performing the specified operation even after errors
have occurred. By default, CIPHER stops when an error is
encountered.
/FForces the encryption operation on all specified objects, even those that are already encrypted. Already-encrypted objects are skipped by default.
/QReports only the most essential information.
/HDisplays files with the hidden or system attributes. These files are omitted by default.
/KCreate new file encryption key for the user running CIPHER. If this option is chosen, all the other options will be ignored.
/WRemoves data from available unused disk space on the entire
volume. If this option is chosen, all other options are ignored.
The directory specified can be anywhere in a local volume. If it
is a mount point or points to a directory in another volume, the
data on that volume will be removed.
/XBackup EFS certificate and keys into file filename. If efsfile is provided, the current user's certificate(s) used to encrypt the file will be backed up. Otherwise, the user's current EFS certificate and keys will be backed up.
dirA directory path.
pathnameSpecifies a pattern, file or directory.
efsfileAn encrypted file path.
Used without parameters, CIPHER displays the encryption state of the current directory and any files it contains. You may use multiple directory names and wildcards. You must put spaces between multiple parameters.


To overwrite deleted data on a volume by using Cipher.exe, use the /w switch with the cipher command. Use the following steps:
  1. Quit all programs.
  2. Click Start, click Run, type cmd, and then press ENTER.
  3. Type cipher /w:driveletter:\foldername, and then press ENTER. Specify the drive and the folder that identifies the volume that contains the deleted data that you want to overwrite. Data that is not allocated to files or folders will be overwritten. This permanently removes the data. This can take a long time if you are overwriting a large space.
    The /w switch is used to overwrite data in unallocated space on the disk.
    Note With mount points in Windows 2000, you can mount a volume on any empty folder on an NTFS volume. When you do this, the mounted volume does not have a drive letter of its own. The only way to address that volume is by using the path where you created the mount point. Therefore, the /w switch requests a path of a folder, and from that, it determines the associated volume to wipe. Because of the way the file system works, the whole volume must be wiped. A file can be written anywhere on the volume at any time. A folder does not address a specific physical location on disk but is a logical container for file entries in the volume's table of contents (MFT or FAT). To make sure that there is no leftover data in unallocated space, all unallocated space on the volume must be wiped.


For more details, look into following links: