I have found Powershell great in gathering basic information on installed Fonts in c:\windows\fonts (Get-ChildItem, using WMI etc) - has anyone got further or been able to not only list the fonts but parse and format the additional information located under the details tab when viewed via the Font applet. I can’t workout where this piece of the puzzle is stored in Windows and whether Powershell can get at it. (I am trying to see if Powershell can pull this from where ever Windows stores, File version, Title, Type etc all under the details Tab)
We have a huge amount of users with varying font sets managed by work areas - we roll out a replacement PC and the phone starts ringing font xxx was on my old machine but is now missing - these are heavy duty Adobe Creative people. Sometimes the same font is on both old and replacement PC but differs by version number
Good point Max. One thing to note, size is also pulled back in the $file object, so I excluded it in the original $details, but I think you’re approach is cleaner, could just skip it in the innermost IF block
I have knocked together the below - what I wasn’t aware of was that some fonts are listed with metadata ‘Font Version’, or ‘File version’ or have nothing at all - so it gets tricky trying juggling the different metadata - especially when you are more on the admin side like me rather than programming side (.Net etc).
I have no remoting (WSMAN enabled) so am going to try and use both Michael’s and the below to get on top of this issue. Sharing the below in case any other admins like me get this issue - please suggest any improvements if warranted
Hey Andrew, what about taking a different approach. Rather than trying to get all of this metadata from the fonts, what about creating a catalog of the fonts based on their hash.
Use Get-FileHash to create a list of all the fonts the user has on their old machines then use those hash values to pull the correct fonts from your catalog and put on the new machine.
Or
If the new and old machine are online at the same time, why not just copy the fonts directly from the old system to the new system. This should ensure all of the fonts are the correct version.
Anyone able to suggest what I might be missing here? Apologies if it is staring me in the face
If I run the get-filehash using the md5 algorithm against the Windows\font directory on two different computers I then use the results in the compare-object cmdlet
example below where $path, $pathdiff are UNC paths to the fonts directory on 2 different machines
What I can’t figure is that I get a few differences in about 6 fonts, if I examine the result of get-filehash used on each machine, the filehash is identical. If I inspect every visible piece of metadata - permissions, version, date created, size etc they are identical also identical - but Compare-Object if flagging them as different
I’ve dealt with Adobe fonts issues in the past. Your savior for this is the Adobe “Document Fonts” folder. You can create this folder under the Adobe project and put the fonts in there for that project. When Adobe loads the project it loads all of the fonts in that folder and you don’t need to install them on the PC. It also allows the end users to manage the fonts and take that workload off of you.
**Rick - Thanks for the reply - will investigate and try and look good for my boss
I am still confused by the behaviour of compare-object - check this out:
Test 1 (the identical font file from 2 x different PCs is copied locally into a test folder)
Compare-Object -ReferenceObject (Get-Item -Path C:\temp\Font_Test\computer1* | Get-FileHash -Algorithm MD5) -DifferenceObject (Get-Item -Path C:\temp\Font_Test\computer2* | Get-FileHash -Algorithm MD5)
Result - no difference - matching hash - great!
Test 2 (UNC path to the exact same font files used in test 1)