So we had recently enabled DNS scavenging for a large environment who also had a DirectAccess server. The next day we were getting help desk calls about remote users not able to connect and those who were in the office unable to use their devices. One of the cornerstones of DirectAccess is DNS and the Network Location Awareness this provides to the clients. We had to re-create the DNS records for DirectAccess manually on one of their DNS server.
- directaccess-corpConnectivityHost which includes both A and AAAA records when deployed on IPv4-only networks. Basically the Loopback addresses for both IPv4 and IPv6.
- directaccess-WebProbeHost this includes only A records and resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server.
- directaccess-NLS should point to the server hosting the Network Location Service, which should be Highly available.
So when building your DirectAccess infrastructure, always remember to set the DNS entries as Static.
I recently had to extract some data from our DirectAccess server to get information about a particular user and their number of connections during a time period along with data transferred. The Remote Access Management Console allows you to view these details but not extract or save them. So I turned to PowerShell and used the following snippet to extract what I needed.
Get-RemoteAccessConnectionStatistics –StartDateTime "1 April 2017 12:00" –EndDateTime "8 April 2017 12:00" | Export-Csv –Path "C:\Temp\DAConnections.csv"
I then cleaned the data up in Excel to give me only the user I was after along with date and times and amount of data transferred. You can also use Get-RemoteAccessConnectionStatisticsSummary and Get-RemoteAccessUserActivity which further drill down into what a particular user has been up to while connected to DirectAccess.
So I’m going through and trying to automate a lot of things in our environment (one thing you should always try and do as a SysAdmin is to automate repetitive tasks) and to help me achieve this I’m using Group Policy, step one is enable Remote Desktop to all of our Servers automatically. Created the Group Policy Object, allowed Remote Desktop Connections and also setup a list of IP Addresses to allow connections from.
After a while I added another IP Address to the exemptions and the next morning I found that I was no longer able to RDP directly to some of my servers, wondering what had happened I logged into our Hyper-V host (where RDP was still working) and I logged onto one of the affected servers. I firstly went and checked to ensure that RDP was still enabled, yup sure is, I then went and checked the Firewall and I spotted a Block and Deny All rule that I was sure I didn’t create. So I went back over the GPO that I had applied, went into the IP exceptions and turns out there was a SPACE separating one of the IP Addresses after the comma. Removed that space, performed a GPUpdate on the affected machines and Remote Desktop started working again.
Starting with Google Chrome 58 no longer trusts certificates without the Subject Alternative Name attribute, so this makes it a little troublesome for those with internal CAs where you rely on them for Software Development. We noticed last week that some end users couldn’t hit an internal application over HTTPS, but was fine in Firefox and IE. After a quick search, I’d found the culprit was a change in the behavior of Google Chrome to adhere more stringently to RFC 2818. So I went to work on our CA in enabling certificates to be requested with the Subject Alternative Name Attribute.
Start an administrative command prompt on one of your intermediate CA server and issue the following command;
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
You’ll then need to restart Certificate Services. Once done, best thing to do is to create a new Template (ours is called Dev Web Servers) along with giving the right permissions to allow users or machines to enroll and begin issuing the new certificates. We do this manually at the moment via the Web interface so when requesting a certificate you need to fill in the attribute text field with the following (like the image to the left)
Fill in the dns= part until you cover off all of the sites you need. Complete the request to install the certificate onto your server and adjust the SSL bindings to use the new certificate.
I was recently helping out a colleague with an SQL Server Reporting Services (SSRS) installation. When it came time to configuring that instance of SSRS and making it listen on port 80 for that particular site we got The URL has already been reserved warning message, navigating to the Reporting Services URLs gives us a HTTP 500 error message.
To find the culprit I can usually use netstat -ab to find what windows process is listening on particular ports but for this instance it was simply SYSTEM, this usually means that an application is using the HTTP.SYS driver to directly listen for requests. So to work around this and find out what has bound to those ports, we use netsh http show urlacl and when I ran it on this server, I could see that ReportServer had already been enabled on Port 80.
Reserved URL : http://+:80/ReportServer/
User: NT SERVICE\ReportServer
Reserved URL : http://+:80/
User: NT SERVICE\ReportServer
I’ll show you two ways to remove these entries that have been incorrectly configured. The first is using the following command
netsh http delete urlacl http://+:80/ReportsServer/
A much easier way I’ve found is to use a tool called HttpCfg.exe written by Steve Johnson which is based on a tool from MS (now obsolete). I’ve got this in my toolbox for the future, but simply open the tool, select the entry and hit delete.
Now we can re-run the SSRS Web server configuration and hit apply which should succeeded this time.
I was looking at an old Exchange environment that was being used to send bulk mail outs. We noticed every now and again a bunch of e-mails would not be getting sent, trawling through Message Tracking Logs we could see that the messages were failing because of an AGENT FAIL which usually means that there is a transport agent blocking those messages.
The customer still wanted the anti-spam agents enabled so instead we used PowerShell to modify the receive connector to bypass the Spam Filtering by giving the anonymous logon extended right ms-exch-bypass-anti-spam. Use the following PowerShell cmdlet and modify the Receive Connector with the name of your Connector.
Get-ReceiveConnector "Receive Connector" | Add-ADPermission
-User "NT AuthorityAnonymous Logon" -AccessRights ExtendedRight
Hope that helps.
I had a VM snapshot/checkpoint running for several months in my test lab and after reverting the snapshot back I went to login to the machine and got the dreaded Trust relationship between this computer and the primary domain failed error message. So I logged in as a local admin onto that machine, opened up an Administrative PowerShell window and entered the below commands.
$cred = Get-Credential – (enter domain admin account when prompted)
Reset-ComputerMachinePassword -Credential $cred -Server ada-dc-02.adatum.com.au
Replace the server at the end with a FQDN of one of your Domain Controllers. As I wasn’t authenticated to the domain, I needed to enter my domain admin credentials by using the Get-Credential cmdlet and then using those stored credentials to issue the Reset-ComputerMachinePassword cmdlet.
So there you have it, no more re-joining a computer to the domain.