VSSADMIN Blocked by Group Policy – Server 2019

I have a 2019 server standard that was giving me this error from an elevated CMD

C:Windowssystem32>vssadmin
This program is blocked by group policy. For more information, contact your system administrator.

This kept me from viewing the state of the writers and troubleshooting a Datto backup issue.

This is the specific error seen in the application log:

Access to C:WindowsSystem32vssadmin.exe has been restricted by your Administrator by location with policy rule {e9e0e074-bb50-497a-8b0e-f357a16a3e4d} placed on path vssadmin.exe.

This led me to this article: https://www.sevenforums.com/tutorials/7844-applocker-create-new-rules.html

I went to the Local Security Policy and exanded to the path below

I created a PATH rule that allowed the specific exe to run. THEN, the magic happened. The server informed me that the default rules for the server had not been created. Would I like to create them now? I said yes, and the three default rules appeared with my new one! Now it works!!!

C:Windowssystem32>vssadmin
vssadmin 1.1 – Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

Error: Invalid command.

—- Commands Supported —-

Add ShadowStorage – Add a new volume shadow copy storage association
Create Shadow – Create a new volume shadow copy
Delete Shadows – Delete volume shadow copies
Delete ShadowStorage – Delete volume shadow copy storage associations
List Providers – List registered volume shadow copy providers
List Shadows – List existing volume shadow copies
List ShadowStorage – List volume shadow copy storage associations
List Volumes – List volumes eligible for shadow copies
List Writers – List subscribed volume shadow copy writers
Resize ShadowStorage – Resize a volume shadow copy storage association
Revert Shadow – Revert a volume to a shadow copy
Query Reverts – Query the progress of in-progress revert operations.

ADMX Files and the Central Store

This guy’s short video is the best no nonsense summary of what to do with new ADMX files.

In short, always overwrite any admx files with ones you KNOW are newer because they are named for the technology affected by the file. So newer is alway better. And if you copy one in and there is no overwrite? You now have totally new features to play with. Look at the XLSL file in the ADMX Zip files.

Exchange 2016 Tracking Log Searches

Exchange 2010 was the last iteration that included a decent message tracking log interface. Microsoft intentionally broke that wonder search app with 2013 in order to push admins to use powershell. So, when I had to track down the internal source of an email that was being sent by a job that did not appear to exist (we have dozens of applications that route mail through Exchange) I had to use PowerShell to track down the source IP.

Image result for exchange powershell

 

This proved not to be the easiest thing to do. I was not sure where the original source IP even resided. So, I decided to start with everything for the first query and work my way back from there. I also decided to use the wonderful | Out-Gridview feature to pipe the output to a GUI so that I could filter from there.

Here is the query to use:

Get-MessageTrackingLog -Server mail01 -Start “Aug 7 2017” -sender “customerservice@domain.com” -resultsize unlimited | select-object TransportTrafficType,SchemaVersion,RunspaceId,Timestamp,ClientIp,ClientHostname,

ServerIp,ServerHostname,SourceContext,

ConnectorId,Source,EventId,InternalMessageId,MessageId,

NetworkMessageId,Recipiets,RecipientStatus,TotalBytes,RecipientCount,RelatedRecipientAddress,

Reference,MessageSubject,Sender,ReturnPath,Directionality,

TenantId,OriginalClientIp,MessageInfo,MessageLatency,MessageLatencyType | Out-Gridview

 

This gave me the information that I needed. Too much information in fact, which was easily remedied by the Out-View Grid’s “Add Criteria” feature. In the end, it was the OriginalClientIP field that gave me what I needed!

 

 

 

 

 

 

Migrate DFS Namespaces from 2000 to 2008 mode

Recently I had a client whom I had migrated AD services from 2008 R2 to 2012 R2. That part of the project went well and when completed, I needed to upgrade their DFS infrastructure to 2008 Mode.

There were issues though and I had to do a few things that I didn’t really like to do. Let’s just say that when you have to use ADSIEDIT.MSC, it’s always a cause for concern!

Image result for distributed file system

Here are a few of the references that I used:

https://technet.microsoft.com/en-us/library/cc753875.aspx – procedure for upgraded DFS Namespaces to 2008 from 2000

https://social.technet.microsoft.com/Forums/office/en-US/d77b1057-7854-45a8-9449-20f64bcc2f48/tried-migrating-dfsr-namespace-from-2000-to-2008?forum=winserverfiles – Use ADSIEDIT.MSC to clean up DFS in AD.

https://blog.workinghardinit.work/2011/05/24/move-that-dfs-namespace-to-windows-2008-mode/ – Good article on the process

These are the steps that I took to upgrade the DFS with errors and the remediations that I found needed to be used.

1: Open an admin CMD prompt:

  • Dfsutil root export \domain.localxyz c:xyz.xml

2: Write down the path for each namespace server:

\Server03xyz

\Server01xyz

\Server02xyz

3: In DFS Management, right-click the namespace and then click Delete

  • Could not delete the entire DFS. Server03 gave an error about the element not being found – DFS – The namespace cannot be queried. Element not found

https://social.technet.microsoft.com/Forums/office/en-US/b64ee068-653d-4f71-8cd7-a693c955bed9/dfs-the-namespace-cannot-be-queried-element-not-found?forum=winserverfiles

  • Bounced the DFS services on all three DCs
  • Able to delete the DFS Namespace but gave an error on Server03, red X on the namespace
  • Deleted Namespace from the AD using ADSIEDIT.MSC

 

  • Open ADSIedit.msc.
  • Connect to Default Naming Context (the domain name)
  • Expand and locate the container, which show the DFS root information
  • CN=<name_of_the_DFS replication group>,CN=DFSR-GlobalSettings,CN=System,DC=<name_of_your_domain>

 

4: In DFS Management, recreate the namespace with the same name, but use the Windows Server 2008 mode

  • At first, gave additional error about Server03 – Access is denied.
  • Could not stop and restart DFS, access is denied
  • Rebooted Server03
  • Now about to stop and start DFS
  • Added namespace back to the DFS successfully

 

5: Import the namespace from the export file

  • Dfsutil root import merge c:pps.xml \Domain.localxyz

Now, all appears to be well.