Home » 2014 » October » 07

Daily Archives: October 7, 2014

Emailing Users when Password is about to Expire

I had one request from a customer recently that asked if it was possible to email users before the their active directory passwords expire as it was causing issues with remote users.

I created a PowerShell script which I added as a scheduled task on one domain controller that runs once  a day. The script queries AD for the date the user last changed their password and compared it against AD password policy maximum age limit. If this reached a specified time such as 5 days before, the user would be emailed once per day with 5 days to go. Please note that you will need an exchange server or mail server that will allow unauthenticated email to be sent from the DC you home this script on.
$from = “passwordreminder@domain.local”
$expireindays = 5
#Get Users From AD who are enabled
Import-Module ActiveDirectory
$users = get-aduser -filter * -properties * |where {$_.Enabled -eq “True”} | where { $_.PasswordNeverExpires -eq $false } | where { $_.passwordexpired -eq $false }

foreach ($user in $users)
$Name = (Get-ADUser $user | foreach { $_.Name})
$emailaddress = $user.emailaddress
$passwordSetDate = (get-aduser $user -properties * | foreach { $_.PasswordLastSet })
$maxPasswordAge = (Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge
$expireson = $passwordsetdate + $maxPasswordAge
$today = (get-date)
$daystoexpire = (New-TimeSpan -Start $today -End $Expireson).Days
$subject=”Your password will expire in $daystoExpire days”
$body =”
Dear $name,
<p> Your Password will expire in $daystoexpire days.<br>
To change your password, Logon to the domain Internal Network on a PC / Laptop, press CTRL ALT Delete and chose Change Password <br>
<p>Thanks, <br>

if ($daystoexpire -lt $expireindays)
Send-Mailmessage -smtpServer $smtpServer -from $from -to $emailaddress -subject $subject -body $body -bodyasHTML -priority High


Precreate 2012 R2 RODC computer object in Active Directory

To pre-create a Read Only Domain Controller account in Active directory using PowerShell perform the following steps

  1. Create a Domain User Account called RODCADMIN and set Password
  2. Create a Security Group called Allowed Prepopulating and add in users you want to allow to cache credentials on a RODC, e.g Domain users and Domain Computers
  3. Run the following Powershell Command
    Add-ADDSReadOnlyDomainControllerAccount -DomainControllerAccountName <RODC Computer> -DomainName <FQDN> -SiteName <AD Site Name> -AllowPasswordReplicationAccountName “<domain>\Allow RODC>” -DelegatedAdministratorAccountName “<domain>\RODCAdmin” -InstallDNS –NoGlobalCatalog –ReplicationSourceDC <Writeable Domain Controller FQDN>
  4. Once created do not join the machine you want to be a RODC to the domain, instead install the AD Domain Services role and then promote to a Domain Controller. These settings should automatically be gathered from AD during this process.

To pre-populate user passwords on a RODC take a look at this script available from technet gallery http://gallery.technet.microsoft.com/scriptcenter/Prepopulate-a-batch-of-34e6d0dc

Assigning everyone permission to read each others calendar Exchange 2013

I had a request from a customer the other week asking if it is possible to grant all users read only permission to each other’s calendars in Exchange 2013. The only way to achieve this in bulk is using Exchange Management Shell. Below is the script I created to filter out distribution, room and discovery mailboxes and apply only to user mailboxes

$LogFile = “c:\CalendarPermissions.txt” ;

$Mailbox = Get-Mailbox -Filter {(RecipientType -eq “UserMailbox” -and Name -notlike “Discovery*”)} -ResultSize Unlimited;

ForEach ($MailUser in $Mailbox){

Set-MailboxFolderPermission -Identity ($MailUser.alias+’:\Calendar’) -User Default -AccessRights Reviewer;
$MailUser.Name | Out-File $LogFile -Append
Get-MailboxFolderPermission -Identity ($MailUser.Name+’:\Calendar’) | Out-File $LogFile -Append;

Write-Host “All Users have been granted Reviewer Rights to $MailUser Calendar” -ForegroundColor Green;

Skype for Business – Enabling Bulk Users

During a Lync 2013 install of over 2000 seats I had to enable bulk groups of users for Lync enterprise voice, PC to PC and Remote Call Control together with different pool assignments and policies. I created a script that would read from a user completed CSV file and enable users with the specified policies and pool associations.

The CSV file must have the following column headers and saved as LyncUsers.csv

ADUsername Pool LineUri SipAddress ClientPolicy ConferencePolicy DialPlanpolicy Voicepolicy ExternalAccessPolicy

The LineURI should be in format of tel:+441870123456;ext=987

The SipAddress should be in the format of sip:useralias@domain.com

If policies are not defined the default policies will be applied

For the script this is in a word document as this website does not allow .ps1 files to be uploaded. please copy the script contents to a notepad file and save with the .ps1 extension


Performing an Authoritative Synchronisation of SYSVOL using DFSR

I came across a scenario the other week where newly promoted 2012 R2 domain controller would not complete it’s initial SYSVOL replication and in doing so was failing to advertise properly as an available authentication server. The only way I was able to resolve this issue was to perform an authoritative synchronisation of the SYSVOL folder using the PDC as the master.

To perform this please follow the following steps. You should install the DFS Replication role to each domain controller in order to use the DFSR command tools.

  1. Open ADSI Edit on the PDC and connect to the default naming context.
  2. Navigate to CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>,DC=<local>
  3. Modify the attribute msDFSR-Enabled=FALSE
  4. Modify the attribute msDFSR-options=1
  5. For AD replication throughout the forest. You can do this by performing repadmin /replicate <other dc fqdn> <pdc fqdn> “DC=domain,DC=local” /full /force
  6. Next modify the msDFSR-Enabled=FALSE attribute on all other domain controllers and repeat step 5
  7. Start the DFSR service on the PDC and set as authoritative
  8. Look for Event ID 4114 in the DSFR event log
  9. Modify the attribute msDFSR-Enabled=True on the PDC
  10. Repeat Step 5
  11. Run DFSRDIAG POLLAD from the PDC
  12. Look for Event ID 4602 to indicate SYSVOL has been initialised
  13. Start the DFSR service on all other domain controllers and you should see Event ID 4114 in each event log
  14. Modify the attribute msDFR-Enabled=True on all other domain controllers
  15. Repeat step 5
  16. Run DFSRDIAG POLLAD on all other domain controllers
  17. SYSVOL should now replicate between all domain controllers having this issue

To force a SYSVOL replication you can use DFSR command line tool from the PDC

DFSRDIAG SyncNow /Partner:<other dc fqdn> /RGName:”Domain System Volume” /Time:5 

Unattended Installation of Exchange 2013

Performing an unattended installation of Exchange 2013 is pretty simple. This is useful if you want to install exchange using custom settings such as renaming the default database or placing the database or log files on separate drives etc.

From the installation media folder open command prompt and use the following command line switches to prepare the Active Directory for Exchange 2013

Setup.exe /PrepareAD /IAcceptExchangeLicensingTerms /OrganizationName “ExchangeOrg”

Once completed run the following

Setup.exe /Mode:install /IAcceptExchangeServerLicenseTerms /r:CA,MB /TargetDir: E:\Exchange /CustomerFeedbackEnabled:False /Mdbname:MBXDB01 /DbFilePath:E:\Databases\MBXDB01.mdb /LogFolderPath:F:\Logs\MBXDB01 

Note: If installing Exchange 2013 on multiple servers and you are splitting the Client Access role from the Mailbox role, you must install the first Mailbox server first BEFORE installing a Client Access Server.

Installing Exchange 2013 Server Pre-requisites

To install Exchange Server 2013 requires certain roles and features. These can be automatically installed via the GUI install of Exchange Server, however it is more efficient to install these via PowerShell

Powershell Command

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation,RSAT-ADDS

This command will install all roles and features required for either the mailbox or client access exchange role.

After the server has rebooted you will need to install the following application packages

UCMA 4.0 SDK http://www.microsoft.com/en-gb/download/details.aspx?id=35463

UCMA 4.0 Client Runtime http://www.microsoft.com/en-us/download/details.aspx?id=34992

Office 2010 Filter Pack http://www.microsoft.com/en-gb/download/details.aspx?id=17062

Office 2010 Filter Pack SP2 http://www.microsoft.com/en-gb/download/details.aspx?id=39668

Reboot once more and then begin the Exchange 2013 Installation.

Powershell Scripts to Export and Import Legacy Exchange X500 addresses

When migrating across AD forests or even performing an offline exchange migration the most over looked process is migrating the user’s legacy X500 address. The reason this is so important is because local email is delivered using the x500 address rather than the SMTP address normally associated with internet email. When you move the user from one unrelated exchange to another the X500 address is not migrated. This means that when users attempt to send an email to a previous contact in their name cache they will receive a bounce back and failed delivery. In order to prevent this situation occurring you can use Powershell to export the legacy X500 address to CSV and then import this into the new AD user object. If you do not have access to Powershell in the legacy domain you can use CSVDE to achieve the same objective.

Export the Legacy X500 Address


Get-ADUser -SearchBase “OU=legacyusers,DC=domain,DC=local” -Filter * -Properties SamAccountName,legacyExchangeDN | Select-Object SamAccountName,legacyExchangeDN | Export-CSV C:\UserExport.csv -NoTypeInformation


CSVDE -s <domain controller FQDN> -d “OU=legacyusers,DC=domain,DC=local” -p SubTree -l SamAccountName,legacyExchangeDN -r objectClass=user -f C:\UserExport.csv

Importing the Legacy Exchange X500 Address to New Domain

On a domain controller or a machine with Active Directory Powershell module installed, copy the UserExport.csv to the root of the C:\ drive

Create a Powershell Script file called legacyusers.ps1. In this file type the following code

Import-Module ActiveDirectory

$Input = Import-CSV C:\UserExport.csv

ForEach ($ADUser in $Input){

if ($ADUser.legacyExchangeDN){

Set-ADUser -Identity $ADUser.SamAccountName -add @{proxyAddresses=”X500:$($ADUser.legacyExchangeDN)”}



Save the file and execute on the domain controller. You can check this has worked by opening an affected AD user object in the new domain and viewing the Attribute proxyAddresses to ensure that this has been added successfully.

%d bloggers like this: