Following an earlier blog on this subject we have just installed another FreeNAS based server. On this occasion it is not used for archiving but as a large repository in the office which allows remote users to upload file to the office.
The configuration was simple enough once we sorted out the disk mirror issues.
For office solutions where large amounts of data storage are required this is an effective way of providing storage without interfering with other workstations.
Our thanks to the boys at FreeNAS.
Wednesday, 17 February 2010
Monday, 11 January 2010
AN ATTEMPT TO RESOLVE THE DNS NAME OF A DC IN THE DOMAIN BEING JOINED HAS FAILED!
We had a problem connecting a newly installed Windows 7 system to a Windows 2008 SBS domain.
We got the message "AN ATTEMPT TO RESOLVE THE DNS NAME OF A DC IN THE DOMAIN BEING JOINED HAS FAILED! PLEASE VERIFY THIS CLIENT IS CONFIGURED TO REACH A DNS SERVER THAT CAN RESOLVE DNS NAMES IN THE TARGET DOMAIN."
We checked all the setting and everything was correct.
We checked through Google and we found a lot of posts relating to this problem but not many where the problem was resolved.
We looked on the Microsoft Technet with the same result.
We tried taking a newly installed Windows 7 machine and adding it to our own domain (Windows 2003) and there were no problems. This points to the server being the issue.
We referred to our copy of Stanek Administrator's guide and on Page 218 we found a command line utility called dnscmd.exe. We ran this utility and found that the DNS server was listening on IP address 192.168.0.2. The only local adaptor was on IP address 192.168.0.210 so this was a problem.
We fixed the DNS set up on the server. The following link will tell you how to restrict the DNS listening devices click here so please amend to your needs
Once we had done this the new computer joined the domain without problem
Further information contact us through our website.
We got the message "AN ATTEMPT TO RESOLVE THE DNS NAME OF A DC IN THE DOMAIN BEING JOINED HAS FAILED! PLEASE VERIFY THIS CLIENT IS CONFIGURED TO REACH A DNS SERVER THAT CAN RESOLVE DNS NAMES IN THE TARGET DOMAIN."
We checked all the setting and everything was correct.
We checked through Google and we found a lot of posts relating to this problem but not many where the problem was resolved.
We looked on the Microsoft Technet with the same result.
We tried taking a newly installed Windows 7 machine and adding it to our own domain (Windows 2003) and there were no problems. This points to the server being the issue.
We referred to our copy of Stanek Administrator's guide and on Page 218 we found a command line utility called dnscmd.exe. We ran this utility and found that the DNS server was listening on IP address 192.168.0.2. The only local adaptor was on IP address 192.168.0.210 so this was a problem.
We fixed the DNS set up on the server. The following link will tell you how to restrict the DNS listening devices click here so please amend to your needs
Once we had done this the new computer joined the domain without problem
Further information contact us through our website.
Wednesday, 23 December 2009
New hosting website
We have just updated our hosting website http://www.hchosting.org.uk
We have enhanced the services on offer and have tried to make the site more presentable and easier to use.
Please pay a visit and give us your feedback.
Seasons greetings to all our clients and visitors
We have enhanced the services on offer and have tried to make the site more presentable and easier to use.
Please pay a visit and give us your feedback.
Seasons greetings to all our clients and visitors
Thursday, 15 October 2009
thefeedyard.com malware removed with stubware
A big thanks to the folk at Stubware.
I have visited a customer complaining of web pages being misdirected.
To say this was a surprise is an understatement. We only rebuilt the machine from new last week end. We installed Panda AV at build time and we copied users' data from the old disk (probably the source of the infection).
We ran Malwarebytes Antimalware which we have found to be pretty good at removing most things not found in normal AV programs. 17 infected items found but problem not solved.
After further inspection of the problem we found that all links in webpages were being hijacked by something called thefeedyard.com. A quick Google of this gave hints to use Malwarebytes so we ran it again and found a few infections ( probably reinfected since the last scan ).
We also found this reference to Stubware. With some concern that this might be software the likes of many registry cleaners we gave it a go. Downloaded, installed and ran it.
True it listed many items which are captured most of which are legitimate, however a click of a button showed only those that were suspect. 4 items in total. Deleted these and rebooted. Problem cleaned up.
So once again many thanks
I have visited a customer complaining of web pages being misdirected.
To say this was a surprise is an understatement. We only rebuilt the machine from new last week end. We installed Panda AV at build time and we copied users' data from the old disk (probably the source of the infection).
We ran Malwarebytes Antimalware which we have found to be pretty good at removing most things not found in normal AV programs. 17 infected items found but problem not solved.
After further inspection of the problem we found that all links in webpages were being hijacked by something called thefeedyard.com. A quick Google of this gave hints to use Malwarebytes so we ran it again and found a few infections ( probably reinfected since the last scan ).
We also found this reference to Stubware. With some concern that this might be software the likes of many registry cleaners we gave it a go. Downloaded, installed and ran it.
True it listed many items which are captured most of which are legitimate, however a click of a button showed only those that were suspect. 4 items in total. Deleted these and rebooted. Problem cleaned up.
So once again many thanks
Tuesday, 13 October 2009
Many thanks Nerdy Dork, we recovered MySQL files OK
That title will mean little to most of you but let me explain.
Earlier this year we built a web based program for a customer. We installed it on one of their Windows machines and they are into the swing of using it. Then disaster! The machine fails. Luckily for us the disk was intact and no data was lost which means that the MqSQL database we set up in our program should be intact. The only problem in being how do I get it across onto the rebuilt machine intact.
A quick search on google revealed this link http://www.nerdydork.com/restoring-mysql-innodb-files-on-windows.html which gave us the advice we needed.
Just to short cut we copied the data folder with the .frm files. We also then copied the complete configuration file - we did not worry about editing parts of it.
Database restored. Day saved. Heart rhythm can return to normal. Stress ball out of the window.
Once again a big thanks to Nerdy Dork and all those out there that give freely of their advice.
Earlier this year we built a web based program for a customer. We installed it on one of their Windows machines and they are into the swing of using it. Then disaster! The machine fails. Luckily for us the disk was intact and no data was lost which means that the MqSQL database we set up in our program should be intact. The only problem in being how do I get it across onto the rebuilt machine intact.
A quick search on google revealed this link http://www.nerdydork.com/restoring-mysql-innodb-files-on-windows.html which gave us the advice we needed.
Just to short cut we copied the data folder with the .frm files. We also then copied the complete configuration file - we did not worry about editing parts of it.
Database restored. Day saved. Heart rhythm can return to normal. Stress ball out of the window.
Once again a big thanks to Nerdy Dork and all those out there that give freely of their advice.
Subscribe to:
Posts (Atom)