PowerShell Script as Scheduled Task works on one OU but not another

Here is my PowerShell script:

$a = "<style>"
$a = $a + "BODY{background-color:white;}"
$a = $a + "TABLE{border-width: 1px;border-style: solid;border-color: black;border-collapse: collapse;}"
$a = $a + "TH{border-width: 1px;padding: 0px;border-style: solid;border-color: black;background-color:thistle}"
$a = $a + "TD{border-width: 1px;padding: 0px;border-style: solid;border-color: black;background-color:palegoldenrod}"
$a = $a + "</style>"

#Load Active Directory Module
if(@(get-module | where-object {$_.Name -eq "ActiveDirectory"} ).count -eq 0) {import-module ActiveDirectory}

# get domain maximumPasswordAge value

$MaxPassAge = (Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge.days

if($MaxPassAge -le 0)

{ 

  throw "Domain 'MaximumPasswordAge' password policy is not configured."

} 

#Send Alert to User

$DaysToExpire = 14

Get-ADUser -SearchBase "ou=3rdLevelA, ou=2ndLevel, ou=1stLevel, dc=domain, dc=com" -searchscope subtree -Filter {(Enabled -eq "True") -and (mail -like "*")} -Properties * | Select-Object Name,@{Name="Expires";Expression={ $MaxPassAge - ((Get-Date) - ($_.PasswordLastSet)).days}} | Where-Object {$_.Expires -gt -1 -AND $_.Expires -le $DaysToExpire} |  ConvertTo-Html -head $a  -body "<H1>Service Account Passwords Expiring Soon</H1>" | Out-File e:\temp\serviceaccounts.html

Send-MailMessage -to email@domain.com -From email@domain.com -Subject "Service Account Passwords Expiring Soon" -Attachments E:\temp\serviceaccounts.html -SmtpServer smtpserver.domain.com

Open in new window


This script runs as a Scheduled Task to check user accounts in AD to see if their password is expiring within the next 14 days.  If the script finds passwords expiring within this 14 day period, it creates a basic html file with those results then emails it to me every day.  It searches users in OUs and it works just fine except when you switch to a particular OU; we'll call the working container 3rdLevelA and the problem container 3rdLevelB.  Both containers have users in them that I know are close to expiring because I've checked them both manually with a separate PowerShell command.

I welcome any advice or ideas as to why this won't work.
bjbouchardAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Vaseem MohammedCommented:
3rdlevelB is sibling or child of 3LevelA?
You need to change value of -searchBase accordingly.
0
bjbouchardAuthor Commented:
3rdLevelB is not a child/sibling of 3rdLevelA.  They are both children/siblings of the next OU (2ndLevel)
0
Vaseem MohammedCommented:
If 3rdLevelB is at same level as 3rdLevelA
Domain.com
   1stLevel
      2ndLevel
         3rdLevelA
         3rdLevelB
Use this.
OU=3rdLevelB,OU=2ndLevel,OU=1stLevel,DC=domain,DC=com

Open in new window


If 3rdLevelB is under of 3rdLevelA
Domain.com
   1stLevel
      2ndLevel
         3rdLevelA
             3rdLevelB
Use this
OU=3rdLevelB,OU=3rdLevelA,OU=2ndLevel,OU=1stLevel,DC=domain,DC=com

Open in new window

0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

bjbouchardAuthor Commented:
As you can see from my actual script on the original question, I've already got that setup.  I simply change the script from this:  OU=3rdLevelA,OU=2ndLevel,OU=1stLevel,DC=domain,DC=com

to this:  OU=3rdLevelB,OU=2ndLevel,OU=1stLevel,DC=domain,DC=com

and that's when it returns no results.  There are accounts expiring within both OUs so I know it's not an issue of me just thinking that there should be results when there aren't.
0
Joshua GrantomSenior Systems AdministratorCommented:
I would make sure that 3rdLevelB is actually an OU and not just a container.

If this works, CN=3rdLevelB,OU=2ndLevel,OU=1stLevel,DC=domain,DC=com

then it is not a true OU

You can tell the difference by the folder icon.
difference.png
0
bjbouchardAuthor Commented:
It most definitely is an OU.  I know the difference between them, and it isn't one of the built-in AD Containers (such as Users or Computers), it's an actual OU.  

Also, I just told the previous expert that it works for 3rdLevelA which is on the same level (child/parent relationship) as 3rdLevelB, so, no, putting CN=3rdLevelB isn't relevant or even a possibility.

Both OUs worked at one time.  I can't tell you what's changed since that time though.
0
Vaseem MohammedCommented:
how many DC's you have? please check the replication status.
0
RAdministratorCommented:
Check if the user whose credentials the task is using has NTFS permissions on the  3rdLevelB OU. OUs have security properties just like any other object.
If it doesn't, (or maybe even if it does), you could change the task to run under the system account.
0
Joshua GrantomSenior Systems AdministratorCommented:
If it works for one and not the other, it definitely sounds like a permission issue.

RAdministrators suggestion could be correct
0
Vaseem MohammedCommented:
is there any kind of delegation setup for the account under which you are performing the task?
are you getting any sort of error?
remove  -and (mail -like "*") from -Filter and see if something shows up.

Try executing just this code
$MaxPassAge = (Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge.days
if($MaxPassAge -le 0)
{throw "Domain 'MaximumPasswordAge' password policy is not configured."} 
$DaysToExpire = 14
Get-ADUser -SearchBase "OU=3rdLevelB,OU=2ndLevel,OU=1stLevel,DC=domain,DC=com" -searchscope Subtree -Filter * -Properties * |
Select-Object Name,@{Name="Expires";Expression={ $MaxPassAge - ((Get-Date) - ($_.PasswordLastSet)).days}} |
Where-Object {$_.Expires -gt -1 -AND $_.Expires -le $DaysToExpire} 

Open in new window

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
bjbouchardAuthor Commented:
Vaseem:  how many DC's you have? please check the replication status.
This has already been checked.  The number of DCs doesn't matter; replication is good.

RAdministrator:  Check if the user whose credentials the task is using has NTFS permissions on the  3rdLevelB OU. OUs have security properties just like any other object.
 If it doesn't, (or maybe even if it does), you could change the task to run under the system account.

I've already checked this and given the user account that's used to run these tasks full control over the OU in question.

Joshua Grantom:  If it works for one and not the other, it definitely sounds like a permission issue.
This is where I am leaning, but it doesn't make sense as the user account used to run the Scheduled Tasks is the same for all tasks and has permissions to the out-file that it writes to, the folder where the out-file resides, the disk where the folder resides, and has the log on as a batch and log on locally rights on the server as well as full permission on the OU that it isn't working on.  The code for the one PowerShell script that checks 3rdLevelA is the exact same code that checks 3rdLevelB with the exception of the OU that it checks.
0
Joshua GrantomSenior Systems AdministratorCommented:
Maybe the distinguished name of the OU was changed or something? Just for amusement, make sure you have advanced features checked in view in ADUC, go to the properties of the OU, go to Attribute Editor and check the distinguishedName attribute
0
bjbouchardAuthor Commented:
Joshua:  That's actually a good suggestion.  I checked and the DN is the same, it hasn't changed.

Any other ideas?
0
bjbouchardAuthor Commented:
Vaseem:  It ended up being what you suggested.  I looked at the Email section of the account with an expiring password and it didn't have an email address.  I can either remove the -and (mail -like "*")  from the filter or simply put an email in there.  Just as a test I put an email in on one of the accounts that was expiring and sure enough it showed up.  Thanks for the help everyone.
0
bjbouchardAuthor Commented:
If the Email section of the properties for an AD User Object is null (nothing there) it won't process the script any further; at least for my particular script.
0
RAdministratorCommented:
Edit: I noticed that my latest question was also answered.

OTOH Vaseem Mohammed mentioned to remove the mail attribute filter because that would limit the search output to email-enabled users. Might that have any impact on your filter output? Especially since you're trying to retrieve service accounts which aren't always mail enabled? I'm just thinking aloud here.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Powershell

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.