file

Get Inactive Users Report for the past 60 days in a multi domain environment

I had a request recently to provide an inactive user report for the past 60 days. Basically, find out which accounts have not logged in for the past 60 days so action can be taken against them.

The request was for a multi domain forest which queries every domain controller and gets the latest lastlogon value by comparing value from each. I wrote a script and wanted to share as other might find it handy too.

 

Get .Net Framework Version for the .DLL & .EXE files

Working with many app/dev teams it is hard to find which version of Dot Net  an application was designed or made in.

Now if your application server has multiple drives and depending on which drive the application resides it may be hard to find this information.

Let’s assume there are two drives C: and D:.

We will start with D: drive as it is easy.

Now the C: drive is a little more work. The above method wont work because C:  drive has system files and depending on your rights you may not have access to them.

You may get the following error:

But there is a way we can get this accomplished. Good old dos commands to the rescue! We are basically going to get a list of .exe and .dll files from the C: drive and then run the above code against it.

Lets capture the files:

Now we have the .EXE files stored in C_EXE_Paths.txt and we query it for .NET versions and save the output to DotNetFiles_C_EXE.txt

Similarly we have the .DLLfiles stored in C_DLL_Paths.txt and we query it for .NET versions and save the output to DotNetFiles_C_DLL.txt

You might get errors for files that do not meet criteria or fails to list .Net version.

This can be surpressed by using:

The output would be similar to:

Now you can import this in Excel and go crazy!  😉

Additionally, if you want to detect what version of .NETis installed on your server here is a cool utility (ASoft .NET Version Detector) to get you the info, as well as download links to the installer in case you need to download and install.

Guide to migrate FRS to DFSR

For most users this article only applies if you have Window 2003/ 2003 R2 Domain Controller in your enviornment that you are planning to get rid off. Pretty soon I hope! 😉

SYSVOL is a folder shared by domain controller to hold its logon scripts, group policies and other items related to AD. All the domain controllers in network will replicate the content of SYSVOL folder. The default path for SYSVOL folder is %SystemRoot%\SYSVOL. This folder path can define when you install the active directory.

Windows Server 2003 and 2003 R2 uses File Replication Service (FRS) to replicate SYSVOL folder content to other domain controllers. But Windows server 2008 and later uses Distributed File System (DFS) for the replication.  DFS is more efficient than FRS. Since windows server 2003 is going out of support, most people already done or still looking for migrate in to latest versions. However migrating FSMO roles WILL NOT migrate SYSVOL replication from FRS to DFS. Most of the engineers forget about this step when they migrate from windows 2003 to new versions.

For FRS to DFS migration we uses the Dfsrmig.exe utility. More info about it available on https://technet.microsoft.com/en-au/library/dd641227(v=ws.10).aspx

In my environment, I am using windows server 2012 R2 server and I migrated FSMO roles already from a windows server 2003 R2 server.

In order to proceed with the migration forest function level must set to windows server 2008 or later. So if your organization not done this yet first step is to get the forest and domain function level updated.

You can verify if the system uses the FRS using dfsrmig /getglobalstate , To do this

1)    Log in to domain controller as Domain admin or Enterprise Admin
2)    Launch powershell console and type dfsrmig /getglobalstate. Output explains it’s not initiated DFRS migration yet.

Before move in to the configurations we need to look into stages of the migration.

There are four stable states going along with the four migration phases.

1)    State 0 – Start
2)    State 1 – Prepared
3)    State 2 – Redirected
4)    State 3 – Eliminated

State 0 – Start

With initiating this state, FRS will replicate SYSVOL folder among the domain controllers. It is important to have up to date copy of SYSVOL before begins the migration process to avoid any conflicts.

State 1 – Prepared

In this state while FRS continues replicating SYSVOL folder, DFSR will replicate a copy of SYSVOL folder. It will be located in %SystemRoot%\SYSVOL_DFRS by default. But this SYSVOL will not response for any other domain controller service requests.

State 2 – Redirected

In this state the DFSR copy of SYSVOL starts to response for SYSVOL service requests. FRS will continue the replication of its own SYSVOL copy but will not involve with production SYSVOL replication.

State 3 – Eliminated

In this state, DFS Replication will continue its replication and servicing SYSVOL requests. Windows will delete original SYSVOL folder users by FRS replication and stop the FRS replication.

In order to migrate from FRS to DFSR its must to go from State 1 to State 3. This step cannot be reversed.

Migration Steps:

Prepared State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 1 and press enter

4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached prepared stat

Redirected State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 2 and press enter

4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached redirected state

Eliminated State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 3 and press enter

4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached eliminated state

This completes the migration process and to confirm the SYSVOL share, type net share command and enter.

Also make sure in each domain controller FRS service is stopped and disabled. This should happen automatically, but please verify.

Additional Info:

The steps listed above are pretty straightforward.  I’d advise to make sure DFSR binaries are current on all DCs for the respective OS versions, then forge ahead 😊

https://support.microsoft.com/en-us/help/2951262/list-of-currently-available-hotfixes-for-distributed-file-system-dfs-technologies-in-windows-server-2012-and-windows-server-2012-r2 (Note: the article has both 2k12 and 2k12R2 binaries by DFS-N and DFS-R, I’m including just the DFSR below)

DFS replication

Windows Server 2012 R2

Date added Knowledge Base article Title Why we recommend this hotfix Hotfix type and availability
Aug 05, 2016 3172614 July 2016 update rollup  for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 This hotfix contains the most current version of Dfsrs.exe for Windows Server 2012 R2. To apply this update rollup, you must be running Windows Server 2012 R2, April 2014 Update 2919355 and April 2015 Update 3021910.
NA This hotfix contains the most current version of Dfsrro.sys for Windows Server 2012 R2. To install this hotfix, you must have Windows Server 2012 R2 installed.
NA This hotfix contains the most current version of Dfsrclus.dll for Windows Server 2012 R2.
August 31, 2014, Install this Hotfix 2996883 DFSR stops replication after an unexpected shutdown in a Windows 8.1 or Windows Server 2012 R2 environment This hotfix contains the most current versions of Dfsrdiag.exe, Dfsrmig.exe and Dfsrwmiv2.dll for Windows Server 2012. To apply this hotfix, you must be running Windows Server 2012 R2 and April 2014 Update 2919355.

 

For any 2008/2008R2 DCs, the parallel article to the 2k12 version above, https://support.microsoft.com/en-us/help/968429/list-of-currently-available-hotfixes-for-distributed-file-system-dfs-technologies-in-windows-server-2008-and-in-windows-server-2008-r2 :

Windows Server 2008 R2

Date added Knowledge Base article Title Why we recommend
this hotfix
Hotfix type and availability
 Oct/11/2014 3002288 DFSR service freezes when it calls a method on a Windows-based server

    Dfsrs.exe 6.1.7601.22842 or newer
This hotfix contains the most current version of Dfsrs.exe for Windows Server 2008 R2 SP1.

Note: For 2008 R2 (RTM) apply: 2725170

To install this hotfix, you must have Windows Server 2008 R2 Service Pack 1 (SP1) installed.
Jan/21/2012 2663685 Changes that are not replicated to a downstream server are lost on the upstream server after an automatic recovery process occurs in a DFS Replication environment in Windows Server 2008 R2 This hotfix adds the ability to enable or disable automatic recovery of DFSR databases via a registry value in Windows Server 2008 R2. (StopReplicationOnAutoRecovery )

 

Set regkey for autorecovery…….

 

On Windows 2012 R2 DFSR Autorecovery is enabled by default

 

To enable the DFS Replication service to automatically recover databases, modify the following registry key:

HKLM\System\CurrentControlSet\Services\DFSR\Parameters\StopReplicationOnAutoRecovery

Notes

·         If the value of the StopReplicationOnAutoRecovery registry subkey is set to 1, the DFS Replication automatic recovery is disabled.
When the error condition should occur you may note a DFS Replication warning event 2213 like the following:

Log Name: DFS Replication
Source: DFSR
Event ID: 2213
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: MyDFSRMember.contoso.com
Description:
The DFS Replication service stopped replication on volume F:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back up the files in the affected replicated folders, and then use the ResumeReplication WMI method to resume replication.

Additional Information:
Volume: F:
GUID: 4A5BAE4E-c19D-21E1-A4E7-007056B54182

·         If the value of the StopReplicationOnAutoRecovery registry subkey is set to 0 or if the StopReplicationOnAutoRecovery registry subkey does not exist, the DFS Replication automatic recovery is enabled.

 

To install this hotfix, you must have Windows Server 2008 R2 or Windows Server 2008 R2 Service Pack 1 (SP1) installed.
Nov/18/2009 975763 DFS Replication does not use Remote Differential Compression (RDC) when replicating very large files on a computer that is running Windows Server 2008 R2 If you have a version of dfsrs.exe installed that is newer than 975763, you do not have to install this hotfix. However, you must still enable the registry change (RpcContextHandleTimeoutMs) that is specified in 975763 for the new behavior to take effect.

 

To install this hotfix, you must have Windows Server 2008 R2 installed. This hotfix is available for individual download and is included in Windows Server 2008 R2 Service Pack 1.
May/21/2013 2851868 “0x0000003B” Stop error when you use the DFSR service on a Windows Server 2008 R2-based This hotfix contains the most current version of Dfsrro.sys for Windows Server 2008 R2 SP1.

 

Dfsrro.sys 6.1.7601.22335 or newer
To install this hotfix, you must have Windows Server 2008 R2 Service Pack 1 (SP1) installed.
Jan/19/2010 979564 The DFS Replication Management Pack shows alerts for cluster network names that are in the “healthy” status on a Windows Server 2008 R2 failover cluster This hotfix contains the most current version of Dfsrclus.dll for Windows Server 2008 R2 RTM. To install this hotfix, you must have Windows Server 2008 R2 installed. This hotfix is available for individual download and is included in Windows Server 2008 R2 Service Pack 1.
Nov/18/2012 2780453 Event ID 4114 and Event ID 4008 are logged in the DFS Replication log in Windows Server 2008 R2 This hotfix contains the most current version of Dfsmgmt.dll for Windows Server 2008 R2 and SP1.

 

Dfsmgmt.dll 6.1.7601.22167 or newer
To install this hotfix, you must have Windows Server 2008 R2 or Windows Server 2008 R2 Service Pack 1 (SP1) installed.

 

As a best practice, as there will be a parallel directory, SYSVOL_DFSR , created during the migration process, have the A-V admins ensure exclusions are set per https://support.microsoft.com/en-us/help/822158/virus-scanning-recommendations-for-enterprise-computers-that-are-running-currently-supported-versions-of-windows

 

Q&A

Q: What are the Domain Controller availability requirements during my migration?

A: There are a couple.

The PDC Emulator must be online any time the DFSRMIG tool is being invoked for a read or write operation. If the PDC Emulator is offline or inaccessible for LDAP, the user of DFSRMIG will receive:

“Unable to connect to the Primary DC’s AD.

Please make sure that the PDC is reachable and try the command later.”

All DCs must remain online until they each complete their state steps. All DCs do not need to be accessible simultaneously. But the global state will never reach the Prepared, Redirected, or Eliminated state until all DCs have been able to complete their individual phases.

The PDC Emulator requirement is because by default, administrators always edit group policy on the PDCE, so in most environments it will have the most up to date knowledge of policy. That and we need to talk to someone unique, so it might as well be him.

It is recommended that a SYSVOL migration not be attempted unless all DCs are online and available. Change control blackouts should be scheduled to prevent modification to DCs that might impact their availability. This will minimize the window of time that the migration will take.

Q: Is there some super-secret way to return to using FRS after reaching the Eliminated phase of DFSR migration?

A: Microsoft does not support returning your domain to using FRS for SYSVOL replication after a completed DFSR migration (except to rebuild the domain). This is why the steps are done in a phased approach with two checkpoints where you can revert back to FRS without any consequences. Once you trigger the ELIMINATED phase to start, there is no going back, period.

Q: When does Robocopy run during the migration and what does it do?

A: The DFSR service uses robocopy at several stages to synchronize SYSVOL directories outside of normal replication when it detects a SYSVOL migration is underway; a set of ‘pre-seeding’ and ‘save the GP admins from themselves’ operations.

When Prepared state (DFSRMIG /SETGLOBALSTATE 1) is invoked, all DC’s robocopy their FRS SYSVOL data locally into the new DFSR content set. This is equivalent to ‘pre-seeding’ data and ensures that minimal file replication occurs to converge the content set. This is triggered by the DFSR service itself when:

  • AD replication has converged between a DC and the PDCE.
  • The DFSR service on that DC has polled (this runs every 5 minutes) and picks up the state change from CN=dfsr-LocalSettings
  • When entering the Redirected state, the PDC Emulator (only) robocopies the local differences of FRS SYSVOL data into the new local DFSR content set, on itself. The other servers receive new data via replication.

If you undo the Redirected state back to Prepared, the reverse happens. The PDC Emulator robocopies its local DFSR content set data into its local FRS content set. FRS replication synchronizes all other servers… eventually. Allow more time for this than entering Redirected, as FRS is not as fast to synchronize as DFSR.

For sharp-eyed readers: we won’t run into any of the old pre-seeding issues (the file hash being changed by robocopy) here because DFSR correctly creates the SYSVOL_DFSR folder ACL, so there are no inheritance issues when the contents are copied in and replicated.

Q: Event 8004 says something about RODC’s. I don’t have any RODC’s. What the frak?

A: The following event is incorrectly written in the DFSR event log(s) on servers that are not Read-only Domain Controllers when setting elimination state using DFSRMIG.EXE:

Log Name: DFS Replication
Source: DFSR
Date: 9/28/2007 11:53:46 AM
Event ID: 8004
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: <WRITABLE DC>
Description:
The NTFRS member object for the Read-only Domain Controller <WRITABLE DC> was deleted successfully.

The text in the event log is completely cosmetic and benign. It is supposed be fixed in a later version of the OS. Just ignore it.

Q: What are all the AD and Registry state values that will be set at a given point in the migration?

A: See below:

=============

Prepared Phase – DFSRMIG /SETGLOBALSTATE 1

  • DFSRMIG contacts the PDC Emulator directly.
  • Global objects are created under:

CN=DFSR-GlobalSettings,CN=SYSTEM,DC=<domain>
CN=DOMAIN SYSTEM VOLUME
CN=SYSVOL SHARE
CN=CONTENT
CN=TOPOLOGY

  • CN=DFSR-GlobalSettings now has msDFSR-Flags attribute set to 0.
  • As DC’s pick up the globalstate change via AD replication and DFSR service polling, they create and write to registry entry:

HKLMSystemCurrentControlSetServicesDFSRParametersSysvolsMigrating Sysvols
Local State = 4 [REG_DWORD]

  • The PDC Emulator creates the:

CN=dfsr-LocalSettings,CN=<servername>,DC=<domain>

objects for all DCs and sets this attribute to:

msDFSR-Flags = 80 (if RWDCs).
msDFSR-Flags = 64 (if RODCs – the RODC itself will set it to 80 later).

  • The DFSR service has now started and created the new local SYSVOL_DFSR structure. Robocopy has made a local copy of the FRS SYSVOL. All AD topology data has been written in to support the content set. Initial sync of the data has started (since robocopy has locally pre-seeded the data this should involve minimal replication data on the network). The registry on all DC’s is:

Local State = 5 [REG_DWORD]

  • Once initial sync is done on all DCs:

Local State = 1 [DWORD] ‘msDFSR-Flags’ (on CN=dfsr-LocalSettings) = 16

  • If DFSRMIG /GETGLOBALSTATE returns that all DCs are prepared, ‘msDFSR-Flags’ on CN=dfsr- GlobalSettings has changed to 16 because all DCs are prepared. All DCs are currently replicating DFSR and FRS content sets, with FRS being shared as SYSVOL.

=============

Redirected Phase – DFSRMIG /SETGLOBALSTATE 2

  • DFSRMIG contacts the PDC Emulator directly.
  • CN=DFSR-LocalSettings now has msDFSR-Flags attribute set to 96 on all DCs and this replicates out through AD.
  • As DCs pick up the attribute from AD replication, their DFSR service sets:

Local State = 6 [REG_DWORD]

  • On the PDC Emulator only, robocopy syncs any changes between the FRS and DFSR’s content sets, and this is replicated out through DFSR.
  • Once SYSVOL data is in sync, SYSVOL content set is set to be the active SYSVOL share on all servers. FRS and DFSR are both still replicating data.
  • When this is complete, for each DC:

Local State = 2 [DWORD] ‘msDFSR-Flags’ (on CN=dfsr-LocalSettings) = 32

  • If DFSRMIG /GETGLOBALSTATE returns that all DCs are redirected, ‘msDFSR-Flags’ on CN=dfsr- GlobalSettings has changed to 32 because all DCs are prepared. All DCs are currently replicating DFSR and FRS content sets, with DFSR being shared as SYSVOL.

==============

Eliminated Phase – DFSRMIG /SETGLOBALSTATE 3

  • DFSRMIG contacts the PDC Emulator directly. At this point it is not possible to undo the changes!
  • CN=DFSR-LocalSettings now has msDFSR-Flags attribute set to 112 on all DCs and this replicates throughout AD.
  • As DCs pick up the attribute from AD replication, their DFSR service sets:

Local State = 7 [REG_DWORD]

  • On the PDC, the FRS content set information is removed and this is replicated through AD. As each DC sees this change, their FRS service stops replicating the FRS content set. The FRS service is stopped (and restarted if custom FRS sets still exist on a given server).
  • When this is complete, for each DC:

Local State = 3 [DWORD] ‘msDFSR-Flags’ (on CN=dfsr-LocalSettings) = 48

  • If DFSRMIG /GETGLOBALSTATE returns that all DCs are eliminated, ‘msDFSR-Flags’ on CN=dfsr-GlobalSettings has changed to 48 because all DCs are prepared. All DCs are currently replicating DFSR only.
  • A final cleanup task on each DC will set their ‘msDFSR-Flags’ on CN=dfsr-LocalSettings to <NOT SET>. The same will happen from the PDC to CN=dfsr-GlobalSettings.

==============

If any ‘undo’ phases are entered (where an administrator has decided to go from redirected back to prepared, redirected back to start, or prepared back to start), the flow above happens in reverse, with the exception that the following two entries exist in the ‘Local State’ registry entries:

  • (Undo Redirecting)
  • (Undo Preparing)

Q: I’m not a huge fan of Ultrasound. Are there any other ways to validate the health of SYSVOL prior to and after migration?

A: Sure thing – already discussed in a TechNet blog post here (Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style).

Q: Are there any migration KBs or bugs I need to worry about?

A: One KB, with a simple solution to domains that have non-standard (and frankly, not any safer than default) security configurations: http://support.microsoft.com/kb/2567421 (Manage Audit and Security Logs user rights required)

CAUSE: The default user rights assignment “Manage Auditing and Security Log” (SeSecurityPrivilege) has been removed from the built-in Administrators group. Removal of this user right from Administrators on domain controllers is not supported, and will cause DFSR SYSVOL migration to fail. DFSR migration and must be run by a user who is a member of the built-in Administrators group in that domain. All DCs are automatically members of the built in Administrators group.

How to restart management agents on ESX or ESXi host

If you are not unable to connect ESXi server to vCenter, or when you cannot connect to ESXi server from VI client it may be necessary to restart the management agents on ESX or ESXi host.

To restart the management agents on ESXi 6.x

This applies to ESX4/5.x/6.x

For the restart of the management agents (mgmt-vmware and vmware-vpxa) do the following:

Log in to SSH or Local console as root.
Run these commands:

Or also (alternative way)
To reset the management network on a specific VMkernel interface, by default vmk0, run the command:

Note: Using a semicolon (;) between the two commands ensures the VMkernel interface is disabled and then re-enabled in succession. If the management interface is not running on vmk0, change the above command according to the VMkernel interface used.

to restart all management agents on the host, run the command:

To restart the Management agents on ESXi Server – via the console:

1.) Connect to the console of your ESX Server and press F2
2.) Login as root and when using the Up/Down arrows navigate to Restart Management Agents.
3.) Press Enter and press F11 to restart the services.
4.) When the service has been restarted, press Enter. Then you can press Esc to logout of the system.

Screen should be similar to:

To restart the management agents on ESXi 4.x and 5.x:

From Local Console or SSH:
  1. Log in to SSH or Local console as root.
  2. Run this command:
You can also check:  Service mgmt-vmware restart may not restart hostd (1005566).

To restart the management agents on ESX Server 3.x, ESX 4.x:

  1. Login to your ESX Server as root from SSH session or directly from the console.
  2. Type service mgmt-vmware restart and press Enter
    Make sure that automatic Startup/Shutdown of virtual machines is disabled before running this command otherwise you might reboot the virtual machines. See more at 103312
  3. Type service vmware-vpxa restart and press Enter.
  4. Type logout and press Enter to disconnect from the ESX Server.

Successful output :

This may also server as a solution for the error “Unable to access file since it is locked. An error occurred while consolidating disks: One or more disks are busy.”

Creating Security Groups for File Shares in Bulk using PowerShell

Security Groups are great for managing large groups for permissions.  A client requested that they needed to have Read-Only, Read-Write, and Ready-Modify (allow for deleting) for all their file shares for better management.

Getting the Share Names

In order for me to create the groups I needed the share names. PowerShell to the rescue!

Type the following on the File Server/ Cluster to list all the shares and capture the output in a text file:

On your file-server you may have a lot of share but for example purposes I am showing just one.

Output should be similar to:

Cleaning up the Share Names

Now that we have the Share names we need to do a bit of cleanup to avoid having duplicates.

  • We need to remove all entries for hidden shares “$”
  • We need to remove duplicates
  • We need to change the case of the share names to lower case. ( I prefer lowercase but you can decide to do what best fits your needs)

Follow my guide to removing duplicates in a text file using NotePad++

Once the sharenames are clean save it to a text file.

Client Requirement for the Security Groups:

For each file share there are three security groups needed:

  • <Sharename>_RO : Read-Only
  • <Sharename>_RW : Read & Write
  • <Sharename>_RM : Read & Modify

For PowerShell to do this I needed to create a .CSV file with all the security group entries.  Now, there are many ways this can be done. I will share what I have been doing.

Open up Microsoft Excel and copy the share on a column to the right (lets say K2)

Now on Cell A2 your value should be =CONCATENATE(K2,"_RW") and drag it down.

It should look something like this:

Do the same for RO & RM. Now you have all the security groups names you need to create.

Create a file called  FileShares_Groups.csv  using the following format.

Create the file Create Security Groups for File Shares.ps1

Copy the two files: FileShares_Groups.csv & Create Security Groups for File Shares.ps1  into a folder called C:\scripts  on the Domain Controller.

Run the PowerShell script and see the security groups get created.

 

 

Remove duplicates, blank lines, spaces, to get unique values and sort data in one operation

From time to time I come across this need; where I need to scrub a file where there are duplicates, there are blank lines, the sort order is all wack, and it just needs to be formatted to where it can be more readable and/or usable.

This method just doesn’t apply to text, but also applies to numbers.

Software Prerequisites:

  • NotePad++
  • TextFX Characters Plug-in for NotePad++

Enabling TextFX Characters Plug-in

Install NotePad++ with all defaults

Goto Plugins > Plugin Manager > Show Plugin Manager

Install TextFX Characters Plugin

Once successfully downloaded it will prompt for a restart.

After a successful restart of the application you should now see the TextFX entry in the toolbar.

Removing duplicates, blank lines, and sorting data

  • Paste the text into Notepad++ (CTRL+V). As you can see, there were lines and half of them were blank.

  • Mark all the text (CTRL+A). Click TextFX → Click TextFX Tools → Check +Sort outputs only UNIQUE (at column) lines (if not already checked).

  • Click TextFX → Click TextFX Tools → Click Sort lines case insensitive (at column)

  • Duplicates and blank lines have been removed and the data has been sorted alphabetically. (The first line that may appear empty contains a space, which is regarded as a character and is included in the list of unique data.)

Changing to lowercase

To change the text to lowercase Goto: TextFX > TextFX Characters > lower case

This has saved me a lot of time when working with IP addresses or cleaning up text.

 

Delete Files and Folders Older Than X Days

Often times admin have to creates tasks like removing log files or some other files on a regular schedule. Here is an automated way of removing files / folders older than X days.

Create a Batch file or Powershell script and add it to scheduled task.

Please check permissions on the files and folders. If you have unique or specialized permission on the file or folders these wont work.

Batch File:

Powershell:

 

Active Directory: Changing passwords for users in bulk using a .csv file

Many accounts in your AD might need a password change. What if you want to do this in bulk ?

First, we need to the userlist. Depending on your requirements we need to get a list of users (specifically samaccountname). For random password generation I recommend using http://manytools.org/network/password-generator/ as it can generate up 1000 for free.

Here is what my UserList.csv look like:

Make sure you do the following on a domain controller or connecting to your domain controller via PS-remote with elevated permissions.

Run this in PowerShell (Open PowerShell in Admin Mode)

PowerShell:

-Reset
Specifies to reset the password on an account. (User is not prompted to change password).
To use this parameter, you must set the -NewPassword parameter.
You do not need to specify the -OldPassword parameter.

Maintain Your Mac – Check the File System for Errors

Use File System Check

Your Mac seems stable and healthy, and you figure you’ve got it made. Because of this, you’re probably thinking you don’t need to check the file system for errors. Don’t do that though, because there may be problems lurking in the background that you can’t see. Just as it’s a good idea to go to the doctor once a year even if you feel great, you need to give your Mac the once-over every once in a while too.

Although you could purchase expensive third-party utilities to search your hard disk for errors and repair them, your Mac OS X machine comes with a built-in utility called File System Check that you can use to do the same thing. File system checks are run using Single-User mode by typing in a simple command. You should perform these checks monthly. To run a file system check now, follow these steps:

1. From the Apple menu, choose Restart.

2. As your Mac boots, hold down the Command+S key combination to start the computer in Single-User mode. (Make sure to press this key combination right after the chime; otherwise, you won’t get in.)

3. At the command prompt, type /sbin/fsck –fy. There’s a space before the –fy. This command tells your Mac to run File System Check, force the check (f) and answer yes (y) to any and all questions regarding fixing, repairing, or salvaging information. Apple says this is the optimal approach because answering no to any question causes fsck to stop running.

4. If the File System Check finds errors, run it again until no more errors are found. You’ll know errors were found if you receive the message “FILE SYSTEM WAS MODIFIED.” You’ll know when all errors have been repaired when you see the message “The volume Macintosh HD appears to be OK.”

5. Type reboot once all of the errors have been found and repaired.