Get All DCs in the Entire Forest

Getting a know a new environment for a new client and I a quickly needed information about all domain controllers in the entire forest.

Wrote a small little script to provide me all the information I needed:


ConfigMgr 2012 R2 – WSUS sync fails with HTTP 503 errors

Ran into this issue with ConfigMgr 2012 R2 where it was unable to synchronize Software Update Point with the WSUS server. A review of the component status messages for the SMS_WSUS_SYNC_MANAGER component on the primary site server reveals errors related to WSUS synchronization which are similar to the following:
Message ID: 6703 WSUS Synchronization failed. Message: The request failed with HTTP status 503: Service Unavailable. Source: Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer.
Got the following error when trying to open Update Services on the WSUS server

Error: Connection Error An error occurred trying to connect to the WSUS server. This error can happen for a number of reasons. Please contact your network administrator if the problem persists. Click the Reset Server Node to connect to the server again.

In addition to the above, attempts to access the URL for the WSUS Administration website (i.e., http://CMCASSERVER:8530) fails with the error:

HTTP Error 503. The service is unavailable

In this situation, the most likely cause is that the WsusPool Application Pool in IIS is in a stopped state, as shown below.

Also, the Private Memory Limit (KB) for the Application Pool is probably set to the default value of 1843200 KB.

If you encounter this problem, increase the Private Memory Limit to 4GB (4000000 KB) and restart the Application Pool. To increase the Private Memory Limit, select the WsusPool Application Pool and click Advanced Settings under Edit Application Pool. Then set the Private Memory Limit to 4GB (4000000 KB).

After the Application Pool has been restarted, monitor the SMS_WSUS_SYNC_MANAGER component status, wcm.log and wsyncmgr.log for failures. Please note that it may be necessary to increase the Private Memory Limit to 8GB (8000000 KB) or higher depending on the environment.

Now WSUS is back online!

Get .Net Framework Version for the .DLL & .EXE files

Working with many app/dev teams it is hard to find which version of Dot Net  an application was designed or made in.

Now if your application server has multiple drives and depending on which drive the application resides it may be hard to find this information.

Let’s assume there are two drives C: and D:.

We will start with D: drive as it is easy.

Now the C: drive is a little more work. The above method wont work because C:  drive has system files and depending on your rights you may not have access to them.

You may get the following error:

But there is a way we can get this accomplished. Good old dos commands to the rescue! We are basically going to get a list of .exe and .dll files from the C: drive and then run the above code against it.

Lets capture the files:

Now we have the .EXE files stored in C_EXE_Paths.txt and we query it for .NET versions and save the output to DotNetFiles_C_EXE.txt

Similarly we have the .DLLfiles stored in C_DLL_Paths.txt and we query it for .NET versions and save the output to DotNetFiles_C_DLL.txt

You might get errors for files that do not meet criteria or fails to list .Net version.

This can be surpressed by using:

The output would be similar to:

Now you can import this in Excel and go crazy!  😉

Additionally, if you want to detect what version of .NETis installed on your server here is a cool utility (ASoft .NET Version Detector) to get you the info, as well as download links to the installer in case you need to download and install.

Speed up Active Directory & DNS replication between Sites

Using the standard GUI Microsoft Management Consoles to make the change to speed up Active Directory replication is not possible. The best result of using administrator consoles will be to increase domain replication between domain controllers to 15 minutes. These large time values were instituted into Active Directory at version 1 because inter-site connections during that era of computing and networking were much lower in bandwidth with the most common being frame-relay or 56k circuits. Since then, inter-site connections and the Internet speeds have increased tremendously so faster domain controller replication is possible even over wan links.

Fast Intersite Replication Interval – Speed up DC Replication, Updates are in Seconds

To enabled faster Intersite Replication, to nearly the speed of intra-site or LAN replication, use ADSI Edit.
Start ADSI edit and go to
Configuration > then Sites > Inter Site Transports > IP.
Note this setting cannot be enabled for SMTP InterSite links.
Unless it has been renamed, right click on  the default Intersite link and choose properties. Then scroll down to the options line. Double-click and change the value to 1 if it has a value .
 <not set> is the default unless this option has been previously modified.  Once changed to 1, click OK twice to save and close the properties window.
Force a replication using Sites and Services so this setting get pushed/pulled to the other domain controllers.
Test by creating a couple of test accounts in AD.
Check your other domain controller or controllers for the new account. You will see it appear in seconds.

Maintain Your Mac – Check the File System for Errors

Use File System Check

Your Mac seems stable and healthy, and you figure you’ve got it made. Because of this, you’re probably thinking you don’t need to check the file system for errors. Don’t do that though, because there may be problems lurking in the background that you can’t see. Just as it’s a good idea to go to the doctor once a year even if you feel great, you need to give your Mac the once-over every once in a while too.

Although you could purchase expensive third-party utilities to search your hard disk for errors and repair them, your Mac OS X machine comes with a built-in utility called File System Check that you can use to do the same thing. File system checks are run using Single-User mode by typing in a simple command. You should perform these checks monthly. To run a file system check now, follow these steps:

1. From the Apple menu, choose Restart.

2. As your Mac boots, hold down the Command+S key combination to start the computer in Single-User mode. (Make sure to press this key combination right after the chime; otherwise, you won’t get in.)

3. At the command prompt, type /sbin/fsck –fy. There’s a space before the –fy. This command tells your Mac to run File System Check, force the check (f) and answer yes (y) to any and all questions regarding fixing, repairing, or salvaging information. Apple says this is the optimal approach because answering no to any question causes fsck to stop running.

4. If the File System Check finds errors, run it again until no more errors are found. You’ll know errors were found if you receive the message “FILE SYSTEM WAS MODIFIED.” You’ll know when all errors have been repaired when you see the message “The volume Macintosh HD appears to be OK.”

5. Type reboot once all of the errors have been found and repaired.