The IP address of a DNS server is almost a in stone written number. That is because the client DNS settings contain the IP address of the DNS server. Some clients are configured via DHCP, others manually, other clients are not known for using this DNS server. But you want catch them all.
So if you come into the situation to relocate your DNS server on the network, build a new machine but you cannot take the IP with you or if you are in the middle of a Active Directory migration project and you have already changed the DHCP settings and you need to find all manually configured machines, especially the unknowns; you can turn on debugging in the Microsoft DNS.
First of all enable the DNS debug logging. Open the DNS management console and click on properties of DNS server. Go to the Debug Logging tab.
Enable Log packets for debugging but disable Outgoing under Packet direction.
Here the PowerShell script to process the debug files.
New-Variable -Name RegexIP -Force -Description "A regular expression object which matches and validates IP addresses." -Value ([regex]'(?<First>2[0-4]\d|25[0-5]|[01]?\d\d?)\.(?<Second>2[0-4]\d|25[0-5]|[01]?\d\d?)\.(?<Third>2[0-4]\d|25[0-5]|[01]?\d\d?)\.(?<Fourth>2[0-4]\d|25[0-5]|[01]?\d\d?)')
$Files = Get-Content "c:\system\DNS\log1.dns.txt"
$RegexIP.Matches($Files)|Group value | foreach {
$chkip=$_."Name"
try { [System.Net.Dns]::GetHostbyAddress($chkip).Hostname }
catch { write-host $chkip }
#write-host $_.Exception.Message
}
The script does two things. First it reads all IP addresses from the log file and group them, and in a second step it tries to get from DNS the hostnames. If it cannot find a hostname for a an IP address it will just list the IP address in the output list.
output example:
PS C:\system> .\ipstat.ps1
win5010.frontoso.com
win5014.frontoso.com
win5052.frontoso.com
win5510.group.frontoso.com
10.0.1.11
10.0.1.10
win5012.frontoso.com
Now you have a list you start from the top, to change the DNS settings of those machines.
Because not every machine is connected every day you may want run the debug more often or for a longer period of time.
If you have multiple DNS servers you can process them all at once. Just append the debug log file name to $Files, seperated all files names by comma
This article targets DNS but if you get a logfile from any other service you could use the same method to identify who is accessing your server/service. e.g. with IIS log files.
Showing posts with label Migration. Show all posts
Showing posts with label Migration. Show all posts
Sunday, August 18, 2013
Saturday, August 11, 2012
Message: This account can't be used to access Outlook.com
Today I ran into an issue accessing the Office 365 Outlook Web Access.
First of all, I made the Office 365 setup for a new tenant. The school of my kids decided to test Office 365, right now they are on Google and they want teach the kids more then one cloud application.
For ADFS we already have a Windows Server 2012. So ADFS works great but the MSOL powershell commands are not working with 2012. But only this server has a public certificate, and the URL is used for other services as well. So I just added ADFS 2.0 to another server, moved the signing cert over and started the MSOL powershell commands. Then I just played copycat to get the relying party settings over to the 2012 ADFS server. After ADFS done I installed and ran DirSync. To verify my doing I went to http://outlook.com/domain.org and after ADFS authentication: BUMMER!
"This account can't be used to access Outlook.com"
So I did some web search, but nothing really helpful came up.
So I compared the relying party settings between the ADFS 2.0 server and the 2012 server and found that I missed to configure the hash algorithm to SHA-1. If it is SHA256 you will see the message above.
I suppose this is only one reason when you see that message because the message is kind of generic.
First of all, I made the Office 365 setup for a new tenant. The school of my kids decided to test Office 365, right now they are on Google and they want teach the kids more then one cloud application.
For ADFS we already have a Windows Server 2012. So ADFS works great but the MSOL powershell commands are not working with 2012. But only this server has a public certificate, and the URL is used for other services as well. So I just added ADFS 2.0 to another server, moved the signing cert over and started the MSOL powershell commands. Then I just played copycat to get the relying party settings over to the 2012 ADFS server. After ADFS done I installed and ran DirSync. To verify my doing I went to http://outlook.com/domain.org and after ADFS authentication: BUMMER!
"This account can't be used to access Outlook.com"
So I did some web search, but nothing really helpful came up.
So I compared the relying party settings between the ADFS 2.0 server and the 2012 server and found that I missed to configure the hash algorithm to SHA-1. If it is SHA256 you will see the message above.
I suppose this is only one reason when you see that message because the message is kind of generic.
Monday, July 16, 2012
In-place migration Windows 2008 R2 to Windows 2012 Certification Authority
I migrated a couple of machine from Windows 2008 R2 to Windows 2012. Greatly it was working well also for remote machines and even a remote access server came back after a while and I could dial in again (Note: I had a SSH connection to the host for backup to get in - I am not that brave.)
Last migration I did was a CA and after migrating I could request certificates and I saw new CRLs. So all is good. Almost, I could not see the MMC for certificate templates and the certification authority.
I had to manually install them first.
or take the shortcut:
c:\>dism /online /enable-feature /featurename:CertificateServicesManagementTools
Small thing but good to know.
Subscribe to:
Posts (Atom)


