Posts made by anthonyh

Oh my lawd. You won't believe the fix.

"Run as administrator"

Why didn't I think of this sooner.

I knew I was missing something stupidly simple.

Even though the account in question is a Domain Admin...

@JaredBusch said in PowerShell - Grabbing Users /w Home Directories:

@anthonyh Stop trying to do the same thing over and over. Definition of insanity and all that.

Take your test user, and dump all the info about it with Powershell.

Then take another user that is showing differently.

Likely you are simply looking at the wrong field, no matter what you think you are wanting.

I disagree with your statement that I was doing "the same thing over and over" (though I don't disagree that I'm totally insane/nuts/etc.), but I digress...

Comparing two accounts, there are obviously differences since the test account I created is a bare bones account.

Test account: https://pastebin.com/eTTx74Va

"Good" account (with redacted info, of course): https://pastebin.com/PDvDUGpB

I don't see any property referencing the home directory UNC path with my test account.

@dafyre Yes, I'm running this on a DC directly.

Not sure if this is related, but I also noticed that the Enabled true/false property that comes with the dump by default only has values for 39 accounts. All the rest (2,717 accounts total) have no value for the Enabled property. Hmm...

So, I created a new user and assigned it a home directory on the server I'm trying to filter for. I ran the following in PowerShell to pull all AD users:

Get-ADUser -Filter * -Property SamAccountName,HomeDirectory,HomeDrive | export-csv -path (Join-Path $pwd AllUsers.csv) -encoding ascii -NoTypeInformation

The user I created is there, but with the HomeDirectory property blank.

However, you can see that it's clearly set in AD:

I is the confused.

Same result on my 2008 R2 DC. 25 accounts returned.

PS Z:\> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
2      0      -1     -1

I feel like I'm missing something obvious here...

@dbeato said in PowerShell - Grabbing Users /w Home Directories:

@anthonyh said in PowerShell - Grabbing Users /w Home Directories:

I just had a friend of mine ( @jrc ) try this in his environment and he gets an expected number of accounts returned respective to his environment.

So it's definitely an issue with my environment. Now to figure that out.

What is your PowerShell version?

Oo, good question.

PS Z:\> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      14393  2828

I am running this from my 2016 DC. I'm going to try it on my 2008 R2 DC (waiting on some hardware before replacing this one /w 2016).

I just had a friend of mine ( @jrc ) try this in his environment and he gets an expected number of accounts returned respective to his environment.

So it's definitely an issue with my environment. Now to figure that out.

@Grey said in PowerShell - Grabbing Users /w Home Directories:

The filter statement in the first command is less than correct. Use curly braces instead of single quotes. Also, consider a where statement:

get-aduser -filter * -property SamAccountName,Homedirectory | where {$_.Homedirectory -eq ''}

Change eq to neq to find the opposite (non-empty).

Sadly, no change. Still only get 25 results when I should be getting 100+.

Get-ADUser -Filter * -Property SamAccountName,HomeDirectory,HomeDrive | where {$_.HomeDirectory -like '*file*'} | export-csv -path (Join-Path $pwd HomeDirs.csv) -encoding ascii -NoTypeInformation

I haven't a clue what I'm missing here...

I'm working on a simple PowerShell script that'll spit out all the users that have a Home Directory currently configured. I'm playing with Get-ADUser and it's not behaving the way I'd expect. I started with the following command:

Get-ADUser -Filter 'HomeDirectory -like "*"' -Property SamAccountName,HomeDirectory,HomeDrive | export-csv -path (Join-Path $pwd HomeDirs.csv) -encoding ascii -NoTypeInformation

However, this seems to only return 26 25 accounts. I know for a fact I have WAY more than 26 25 accounts with Home Directories. So, I took a step back by trying the following:

Get-ADUser -Filter * -Property SamAccountName,HomeDirectory,HomeDrive | export-csv -path (Join-Path $pwd HomeDirs.csv) -encoding ascii -NoTypeInformation

This returns what looks like all users in AD. However, many users that have a Home Directory configured have an empty/null HomeDirectory property.

I am baffled as to why this is happening. Does anyone have any suggestions?

EDIT: Changed record count from 26 to 25...forgot to account for the CSV header.

I figure I'd just throw this out there just for the heck of it...

For what it's worth, I use a Cisco ISR 2851 as an FXS and FXO gateway in my home lab and am very happy with it. You can nab them pretty cheap on eBay (either a 2851 or 2821 would work). You'd just need either two VIC2-4FXO cards or for the more adventurous an EVM-HD-8FXS/DID with two EM-HDA-6FXO daughter cards and something to terminate the RJ21 connector with (like a 66 block or a breakout cable)...the former is likely easier though :grinning_face_with_smiling_eyes:

Just a side note: I can confirm that @Dashrender 's suggestion of creating a CNAME works like a charm. I created a new software deployment GPO and added the source via the CNAME record and deployment was successful.

@notverypunny said in GPO Software Deployment Woes:

Is your filesrv02 the actual name of the machine? I remember seeing a mention of using a DNS record... I may be wrong but IIRC DNS redirection and modern SMB don't always work together very well because Kerberos. Like I said, might be completely out to lunch on this one, still working on my 1st coffee of the day.

Yes, that is the actual name of the host I have moved the files to. @Dashrender was the one that suggested to use a CNAME in the future, which I will experiment with since if it works would make future moves (though years out likely) much easier.

The original host was dc01, and the desire was to move the files to filesrv02. I had followed the article @dbeato posted (https://support.microsoft.com/en-us/help/2395088/how-to-change-the-msi-file-location-in-the-software-deployment-gpo-mut) before starting this post here.

I re-created the share on the "new" dc01, even after re-pointing the msiFileList on all of my Software Install GPOs to filesrv02. This satisfied the GPOs and on my test VM they all ran and installed without fuss.

This tells me that even though I updated the msiFileList property (removed the old value and replaced it with new, which was simply changing the server. The share name and all permissions were identical), and even though gpresult was reflecting the new path, somewhere somehow things were not truly obeying this.

I even went as far as to enable file auditing on the share on filesrv02 and, sure enough, I saw zero attempts at any connections when a machine failed through the software install GPOs.

So, for now, I've left the share in both locations and have updated the msiFileList property on the software install GPOs to reflect my "preferred" location (not ideal for sure). I think I'll revisit this once the other DC has been demoted and replaced with a Server 2016 host.

@dbeato said in GPO Software Deployment Woes:

Also diplicate the GPO and then setup a TEST ou and test it there with a VM or Desktop you can test.

Yeah. I'll do that. I'll set up a GPO software deployment in a test OU and then remove/re-add the package and see what happens.

@dbeato said in GPO Software Deployment Woes:

@anthonyh said in GPO Software Deployment Woes:

@dbeato said in GPO Software Deployment Woes:

@anthonyh said in GPO Software Deployment Woes:

@dbeato said in GPO Software Deployment Woes:

@anthonyh said in GPO Software Deployment Woes:

Alright, for the heck of it, I re-created the share on my new DC (it assumed the same name as the DC it replaced, which was the DC originally hosting these files). And, guess what? All of the software installation policies applied successfully.

So even though I'm changing the msiFileList in ADSI Edit, it's not applying somewere. Even though looking at the Deployment Information of the GPOs shows the modified path, and running gpresult shows the modified path.

What the heck?!

I may just kick this can down the road a bit and re-visit it later unless anyone has any ideas?

For the heck of it, do you get to access the share while on Windows Explorer?

Yes. I think the problem is somewhere in the bowels of the GPOs the path isn't updating.

Yes, I was typing this before:

“
Just for my own sanity reading this Thread, did you actually import each software back again from the new share? Because sometimes that is what it takes”

No, I haven't tried that. Can you delete and re-add software packages to the GPO without it triggering an attempt to re-install them? I want to avoid triggering all of my clients to re-install everything and then wig out because it's all already installed...if that makes sense.

You can do this
https://support.microsoft.com/en-us/help/2395088/how-to-change-the-msi-file-location-in-the-software-deployment-gpo-mut

Or redploy the application, I assume you have set the Package to uninstall when it falls out of the scope?

That link is the exact article I followed.

Some are set to uninstall when out of scope, some are not.

@dbeato said in GPO Software Deployment Woes:

@anthonyh said in GPO Software Deployment Woes:

@dbeato said in GPO Software Deployment Woes:

@anthonyh said in GPO Software Deployment Woes:

Alright, for the heck of it, I re-created the share on my new DC (it assumed the same name as the DC it replaced, which was the DC originally hosting these files). And, guess what? All of the software installation policies applied successfully.

So even though I'm changing the msiFileList in ADSI Edit, it's not applying somewere. Even though looking at the Deployment Information of the GPOs shows the modified path, and running gpresult shows the modified path.

What the heck?!

I may just kick this can down the road a bit and re-visit it later unless anyone has any ideas?

For the heck of it, do you get to access the share while on Windows Explorer?

Yes. I think the problem is somewhere in the bowels of the GPOs the path isn't updating.

Yes, I was typing this before:

“
Just for my own sanity reading this Thread, did you actually import each software back again from the new share? Because sometimes that is what it takes”

No, I haven't tried that. Can you delete and re-add software packages to the GPO without it triggering an attempt to re-install them? I want to avoid triggering all of my clients to re-install everything and then wig out because it's all already installed...if that makes sense.

@dbeato said in GPO Software Deployment Woes:

@anthonyh said in GPO Software Deployment Woes:

Alright, for the heck of it, I re-created the share on my new DC (it assumed the same name as the DC it replaced, which was the DC originally hosting these files). And, guess what? All of the software installation policies applied successfully.

So even though I'm changing the msiFileList in ADSI Edit, it's not applying somewere. Even though looking at the Deployment Information of the GPOs shows the modified path, and running gpresult shows the modified path.

What the heck?!

I may just kick this can down the road a bit and re-visit it later unless anyone has any ideas?

For the heck of it, do you get to access the share while on Windows Explorer?

Yes. I think the problem is somewhere in the bowels of the GPOs the path isn't updating.

Alright, for the heck of it, I re-created the share on my new DC (it assumed the same name as the DC it replaced, which was the DC originally hosting these files). And, guess what? All of the software installation policies applied successfully.

So even though I'm changing the msiFileList in ADSI Edit, it's not applying somewere. Even though looking at the Deployment Information of the GPOs shows the modified path, and running gpresult shows the modified path.

What the heck?!

I may just kick this can down the road a bit and re-visit it later unless anyone has any ideas?

@wrx7m said in GPO Software Deployment Woes:

@anthonyh Have you created a new GPO from scratch too?

No, that's something to test too.

I'd really like to get these existing Software Installation GPOs working if at all possible. I imagine there will be some havoc if I delete and re-create them...

@wrx7m said in GPO Software Deployment Woes:

Hmmm. What if you create a new share and see if that works?

Yeah, that's an option. I may try this first to see if I can get some clarification on if it's even attempting to hit the share first...

https://www.rootusers.com/configure-file-access-auditing-in-windows-server-2016/