How To Enumerate File Shares On A Remote Windows Computer With PowerShell

It can be challenging to keep track of just what file shares have been set up in your environment. This becomes even more difficult if you have to track this information across multiple servers. Adding to the tedium is remotely connecting to each server to find the list the shares. Thankfully, using PowerShell makes this task a snap, whether you need to enumerate shares on just one server, or many.

Enumerate Shares on a Single File Server

Let’s start by connecting to a remote file server to gather this information from a single server. We will accomplish this by entering into a remote PowerShell session with our file server “FILE01”.

Once connected, it takes a single cmdlet to get file share information:

As you can see, this gives us a list of all of the share on this server. This also includes the administrative shares, whose share names are appended by $.

This does accomplish the task of getting a list of shares, but it is a little cluttered. We can clean up this list by using the -Special parameter and setting it to $false to specify that we do not wish to see the administrative shares:

There, that gives us a much clearer view of the share information we are looking for.

Now that we have our share on this server identified, it might be useful to list all of the properties for this share, especially if we are looking for specific details about our share:

This allows us to view quite a bit of information about our share, including things like the type of share, folder enumeration mode, caching mode, and of course, our share name and path, to name a few.

It is also possible to view the share permissions for this share by switching to the Get-SmbShareAccess cmdlet:

This gives us a list of the users and groups, and their current level of access to the share.

We might also have a time where we need to enumerate the share permissions to find out who has full access to a share:

With this information, it is easy to tell who has full access to the share and then take steps to remove that access if it isn’t appropriate for an individual or group.

Now that we are done enumerating shares on a single server, we need to make sure we close our remote PowerShell session:

Enumerate Shares on Multiple File Servers

It is also possible to retrieve this same information from multiple file servers, which is an area where PowerShell really shines. Using Invoke-Command to run Get-SmbShare, we can list the shares on both the FILE01 and FILE02 servers. If we also pipe the output through Format-Table, we can also get a nice organized list:

While entering the file server names manually is fine if there are only two or three servers, it becomes tedious if there are many dozens of servers to check. To get around this, we can assign the output of Get-ADComputer to the variable $FileServAD and get a list of all servers in the “File Servers” Organizational Unit (OU). From there, it’s easy to get the information:

There we have it! A nice tidy list of all of the file shares on all of our file servers.

Additional Resources

Companion Video: “How To Enumerate File Shares On A Remote Windows Computer With PowerShell

How Did I Arrive at TechSnips?

Photo by Danka & Peter on Unsplash

Where I Came From

It’s been about 4 years since I decided that I was no longer content to simply use the Internet as a source of information. I knew at that time that I wanted to give back to the online IT community that had helped my career along for so many years. It seemed that the easiest way to begin was to start a blog. Since I already had one created, one that had been all but abandoned, I thought this was a good place to start.

So, in May 2014 I started blogging. I started off by writing once a week about what I had learned during my MSCE studies, as it gave me a good, constant source of ideas. A few months later, I decided to launch a second blog that would focus primarily on Windows Server and PowerShell tips & tricks, guides, lab setups, and walk-throughs. This is where I ran into a bit of a wall.

I was struggling to find ideas that I thought would be interesting to others. The “Imposter Syndrome” was in full force. I just didn’t think I had anything worth sharing, certainly nothing that hadn’t already been done before. That is where I finally stalled out and all but quit writing.

Over the next few years, my writings continued but were quite sporadic as I was still struggling to come up with ideas. It wasn’t until I read an article by Don Jones titled Become the Master, or Go Away that I realized just how much this imposter syndrome was holding me back.

It didn’t immediately break me out of my shell, but it did help me renew my interest in writing. I even thought about creating videos to go along with the blog posts. I still had the same problem though, no idea about what to write about.

How I Got Here

I have always found it interesting how timing plays such an important role in life, and this is one of those times. I had just finished reading “Be the Master” by Don Jones, and found myself resolved to start doing something right away. A few days later I read a guest post written by Adam Bertram on the blog hosted by Mike F. Robbins. The article, TechSnips is Looking for Content and Recruiting Contributors was a good read, and I felt that it was something I should seriously look at.

By the time I got to this part of the article: “You will learn presentation skills through feedback from myself and your peers…” I had already decided that this was something I was going to do. No doubt about it. A chance to record how-to videos sounded like a great idea. Then I read the words “and you will get paid”. This was the icing on the cake!

So, I clicked on the sign-up link, provided the required information, and submitted an audition video. Waiting to see if I would be accepted as a contributor was the longest 14 hours ever. I finally received the e-mail I had hoped for! I was accepted as a contributor to TechSnips, and I was even provided with feedback on this video so that I could improve the next video I recorded.

My Experience So Far

I didn’t know it at the time, but one of the first things I would learn about TechSnips is that everything moves quickly. It can be quite a refreshing change of pace if you’re used to things moving at a slower cadence. I have found that pace to be very motivating and quite exciting, and I love the fact that changes to TechSnips are made quickly and frequently as the business evolves. Keeping up with the changes was a challenge at first, but I quickly adjusted.

One of those changes that were made during my first few weeks was the introduction of contributor blog posts. The thing I enjoyed most about that change was the fact that Adam went from ‘No, I don’t think we are going to do blog posts’ to ‘yes we are, and here’s how we are going to do it’ inside of a single sentence. So, as you can see, changes are made rapidly.

The second lesson I learned was that there is always feedback being provided, and at every stage of the production process. For me, this advice is invaluable, as I am quite new to producing videos. The great thing about the advice is that it doesn’t just come from Adam but from everyone. If you have a question, whether it be about submitting a video, or setting up a recording environment on a budget, a quick post to the Slack channel will usually elicit a rapid response with helpful and valuable advice.

Having access to this group of professionals has been a wonderful learning experience, as everyone brings their own skills and unique point of view to the team.

TechSnips also successfully addressed the issue I was having with generating ideas. There is always a constant supply of ideas, both from the other contributors, subscribers and sometimes from Adam himself. Once I took a look through those lists of ideas, I realized just how much I had to offer the community. Imposter syndrome….deleted! Well, not entirely, but it isn’t as ever-present as it used to be.

The production quality at TechSnips impressed me right from day one. Every time I submit a video or a blog post, I think to myself “Yeah, that looks pretty good.” Then the editors get a hold of it and give it this incredibly polished look. I will confess to being happily surprised at how good that first video looked after the editing was complete. Now, I find myself anxiously awaiting the final product every time I submit a new video. I just can’t wait to see how good they look.

I am having an absolutely fantastic time with TechSnips! I haven’t had this much fun or felt this excited to work on a new project in a very long time. The sense of teamwork, constant advice, support, and being able to see my content published alongside the that of so many other professionals has been quite rewarding. I cannot think of anywhere better to spread my wings and learn some new skills. I have found everything I need here; Training, guidance, teamwork, ideas, and enough work and excitement to keep me coming back for more.

I would highly recommend to anyone who is thinking about publishing content to give TechSnips a try. There is nothing to lose from the attempt, and so very much to gain.

How to Manage DNS Records with PowerShell

Most of the time, DNS records are managed dynamically by your DNS server. However, at times you may find that you need to manually create, edit, or remove various types of DNS records. It is at times like this that PowerShell is quite useful for managing these records.

Viewing DNS Records

You can view all of the resource records for a given DNS zone by simply using the Get-DnsServerResourceRecord cmdlet and specifying the zone name parameter:

As you can see, this generates quite a lengthy list of records. This nicely highlights one of the advantages of this particular cmdlet over the graphical DNS console. This view gives you all of the records for this zone, regardless of which folder they are in. In the graphical console, it would take quite some time to piece this information together.

Now, let’s thin out this list a bit. Using the same cmdlet, but adding the RRType parameter to search for A records (IPv4 hosts) and filtering for records where the Time To Live (TTL) is greater than 15 minutes gives us a bit more of a manageable list:

Taking this one step further, we can also search for records in a different DNS zone, on a different DNS server. In this example, we will search for A records in the “canada.corp.ad” zone on DNS server DC03:

Adding and Removing Host Records (A and AAAA)

To add a host record, we will need to use the Add-DnsServerResourceRecordA cmdlet. In this example, we need to add a host record for a new printer that we are adding to the network. It will be added to the corp.ad zone with the name “reddeerprint01”, and it’s IP address is 192.168.2.56.

If it turns out that we need to remove a record, for example, if the printer has been decommissioned, we can use the following code to remove the host record that we just created:

It is also just as easy to add an IPv6 host record. Of course, these records differ slightly, as they are listed as AAAA records. You may notice that we are now using the Add-DnsServerResourceRecordAAAA cmdlet. It’s a subtle change, but an important one. Let’s add a record to the “corp.ad” zone for the new IT Intranet server at “fc00:0128” and then quickly verify that it has been created:

Adding Reverse Lookup Records (PTR)

A reverse lookup record allows the client to query a DNS server to request the hostname for a supplied IP address. Creating a PTR record is a relatively easy process, but there is one important bit of information you will need to know before you start adding PTR records. Reverse lookup zones are not created by default. You will need to set up your reverse lookup zone prior to adding records.

Fortunately, it is relatively easy to do. You just need to use the Add-DnsServerPrimaryZone cmdlet and provide it with the Network ID. In this example, I have also chosen to set the replication scope to the entire AD forest, and I have specifically targeted “DC03” as the preferred DNS server:

Now that our reverse lookup zone is in place, we can add our PTR record for a new printer called “CYQF-Printer-01.canada.corp.ad” that has an IP address of 192.168.2.56. As this record is for the “canada.corp.ad” zone, we will be targeting the DNS server “DC03”.

When using the Add-DnsServerResourceRecordPtr cmdlet, it is important to note a couple of things. First, that you need to specify the zone name using the network ID in reverse order, then add “.in-addr.arpa”. So for our “192.168.2.0/24” network ID, the zone name is “2.168.192.in-addr.arpa”. Second, the “Name” parameter is simply the host portion of the IP address. For our printer at 192.168.2.56, the “Name” is simply “56”.

Once you have those pieces of information, the code required to create the PTR record is relatively simple, if a bit long:

Adding Alias Records (CNAME)

To finish off, we will create a host alias record or CNAME record using the Add-DnsServerResourceRecordCName cmdlet. These records allow you to specify an alias for an existing host record in the zone. This becomes especially useful, for example, if you want to provide your finance users with an address for their web-enabled finance app. You could create an alias called “finance”, and point it to the web server “webapp25.corp.ad”. Then when you need to migrate the app to a new web server with a new hostname, you simply change the CMANE record to point “finance” to the new host. This way, the users don’t have to update their bookmarks. They can continue to access their application using the address “finance.corp.ad”.

Additional Resources

Companion video: “How To Manage DNS Records With PowerShell

Using Set-DnsServerForwarder and Others to Manage DNS Forwarders

Using Set-DnsServerForwarder

Windows DNS Forwarders and Conditional Forwarders are an important part of your DNS infrastructure. You will find that on occasion you need to add or manage these forwarder addresses and that some of these changes need to be made across multiple DNS servers in your enterprise. Thankfully, using commands like PowerShell’s Set-DnsServerForwarder cmdlet and others allow you to easily manage both of these DNS services with ease.

Using Set-DnsServerForwarder to Replace Forwarders

DNS Forwarders are used by the DNS server to lookup queries for addresses that aren’t contained in any zones that the server is authoritative for. This provides your DNS servers with an efficient means for resolving names. Without the forwarders in place, your DNS server would have to query the root hint servers in order to start resolving unknown addresses. While these forwarder addresses are configured separately on each DNS server, using PowerShell makes managing them a lot easier by allowing us to use the Set-DnsServerForward command among others.

So, let’s begin by viewing the currently configured forwarders for the local DNS server by using the Get-DnsServerForwarder cmdlet. We’ll use the Set-DnsServerForwarder in a minute to add one.

As seen below, there are two forwarders configured, as listed beside “IPAddress”

Using Get-DnsServerForwader

Next, we want to add an additional forwarder, possibly a new DNS server that we have configured in our DMZ, or perhaps using a forwarding address provided by our ISP. In this case, we’ll use the Set-DnsServerForwarder cmdlet to set the new address and then use Get-DnsServerForwarder to confirm that the address was set correctly.

The results of using Set-DnsServerForwarder

Unfortunately, this did not have the desired outcome. As you can see here, using the Set-DnsServerForwarder cmdlet actually replaces the list of forwarders rather than adding to it. In order to add the address to the list, rather than replacing the entire list, you need to use Add-DnsServerForwarder. To correct this, what we’ll do is replace the list with the original two forwarders, add the new address, then check to see if we are successful.

Get-DnsServerForwarder

There, that looks much better. We now have all three forwarders added.

Now, if you want to remove a forwarder address, you would simply use the Remove-DnsServerForwarder cmdlet as shown, then check to see if the address has been removed. If Set-DnsServerForwarder replaces the DNS forwarder, Remove-DnsServerForwarder removes it completely.

The results of Remove-DnsServerForwarder

Sometimes, you will need to be able to add or remove a forwarder address on multiple DNS servers. In this instance, Set-DnsServerForwarder will not work. Thankfully PowerShell makes scaling this task to multiple DNS servers relatively easy. If we use Invoke-Command, include a list of all of our DNS servers, then put Add-DnsServerForwarder into the ScriptBlock, we can modify all of the DNS servers with a single command. Then using a similar command, view the results of our changes.

Running Get-DnsServerForwarder on multiple servers

That brings us to the end of the section on DNS Forwarders.

Conditional Forwarders

A special type of forwarder, called a conditional forwarder, cannot be modified with theSet-DnsServerForwarder cmdlet but can be used when you have been provided with the IP address(es) of the DNS server(s) for a known DNS domain name. Conditional forwarders are used by the DNS server before using the server forwarders listed earlier in this article. For example, if you have a conditional forwarder configured for tailspintoys.com, your DNS server will, after checking that it isn’t a domain it is authoritative for,  check the conditional forwarders and find that an entry exists. At this point, your DNS server queries the DNS server listed for the desired address in the tailspintoys.com domain.

One nice feature of conditional forwarders is that they can be replicated to other DNS servers in the same way that any Active Directory Integrated DNS Zone can be.

Let’s start by checking to see if we have a conditional forwarder configured by using the Get-DnsServerZones cmdlet.

Get-DnsServerZone PowerShell

Conditional forwarders show up in this list as ZoneType: Forwarder. In this case, we don’t seem to have one configured. So, we will use Add-DnsServerConditionalForwarderZone to create the conditional forwarder, set it to replicate to the entire Active Directory forest, and then confirm it has been created.

The results of Add-DnsServerConditionalForwarderZone

The output shows that we have our conditional forwarder configured, and it is ready to go. PowerShell really does make managing DNS forwarders a snap.

Additional Resources

Companion video: “How To Manage DNS Forwarders With PowerShell