In Chrome on a client computer, each time she'd open a window, you could see the browser looking to the site mnh.winnermore.info for content. This included when she'd click to reply to a message within her Exchange webmail. There was no program in add/remove programs. There were no extensions in Chrome. Malwarebytes, rkill, adwcleaner, and all other cleaners I use found nothing.
This problem persisted in even a new Chrome user profile (same Windows profile). I even searched through the registry and found nothing. Eventually, I came across this site:
http://greatis.com/blog/adware/remove-mnh-winnermore-net.htm
Per the page above, the fix was to set Chome to default settings. This worked. I don't know how/why, but somehow this site embeds itself somewhere I couldn't find it at all.
Sunday, March 29, 2015
Friday, March 20, 2015
Autodiscover points to incorrect location after cpanel update
For a domain on Office365, I had autodiscover stop working. My main clues were that user setups would not autoconfigure and Outlook would lose its Outlook RPC over HTTPS settings.
The problem was that a cpanel update created an autodiscover entry that superseded the standard autodiscover entry that Microsoft suggested customers put in place. This would affect domains in these situations:
1) Use Exchange as their email server (Office365 or any other Exchange server, on premise or outsourced)
2) Have a valid third party SSL certificate on their web site
3) Use WHM/cpanel on their web server
My clue that autodiscover was pointing to the wrong location (aside from the aforementioned problems) was that server replying with autodiscover.xml information was the domain's web server when running the Outlook Autodiscover test from https://testconnectivity.microsoft.com.
Implementations vary, but typically autodiscover (for Office365 at least) will be configured by a CNAME record of autodiscover.domain.com to autodiscover.outlook.com. In the case here, a WHM/cpanel update created a autodiscover response at https://domain.com/Autodiscover/Autodiscover.xml. Outlook checks https://domain.com/Autodiscover/Autodiscover.xml before it checks https://autodiscover.domain.com so if Outlook finds a response at https://domain.com/Autodiscover/Autodiscover.xml, you will have a problem.
In the case of the WHM/cpanel update, https://domain.com/Autodiscover/Autodiscover.xml would forward to https://cpanelemaildiscovery.cpanel.net/autodiscover/autodiscover.xml - which gave the incorrect autodiscover response.
There are two fixes.
The first/proper fix is to disable autodiscover using WHM. Log into your WHM in your web browser and log in as root. In my case, I logged in to my BlueHost WHM via http://123.123.123.123/whm (where 123.123.123.123 is your server's IP address). Go to Server Configuration -> Tweak Settings. Make sure Proxy subdomains is turned ON. Make sure Thunderbird and Outlook autodiscover and autoconfig support are turned OFF.
The second/manual fix (courtesy of comment at 2/14/2015 10:21 AM at http://community.office365.com/en-us/f/156/t/293985.aspx):
The problem was that a cpanel update created an autodiscover entry that superseded the standard autodiscover entry that Microsoft suggested customers put in place. This would affect domains in these situations:
1) Use Exchange as their email server (Office365 or any other Exchange server, on premise or outsourced)
2) Have a valid third party SSL certificate on their web site
3) Use WHM/cpanel on their web server
My clue that autodiscover was pointing to the wrong location (aside from the aforementioned problems) was that server replying with autodiscover.xml information was the domain's web server when running the Outlook Autodiscover test from https://testconnectivity.microsoft.com.
Implementations vary, but typically autodiscover (for Office365 at least) will be configured by a CNAME record of autodiscover.domain.com to autodiscover.outlook.com. In the case here, a WHM/cpanel update created a autodiscover response at https://domain.com/Autodiscover/Autodiscover.xml. Outlook checks https://domain.com/Autodiscover/Autodiscover.xml before it checks https://autodiscover.domain.com so if Outlook finds a response at https://domain.com/Autodiscover/Autodiscover.xml, you will have a problem.
In the case of the WHM/cpanel update, https://domain.com/Autodiscover/Autodiscover.xml would forward to https://cpanelemaildiscovery.cpanel.net/autodiscover/autodiscover.xml - which gave the incorrect autodiscover response.
There are two fixes.
The first/proper fix is to disable autodiscover using WHM. Log into your WHM in your web browser and log in as root. In my case, I logged in to my BlueHost WHM via http://123.123.123.123/whm (where 123.123.123.123 is your server's IP address). Go to Server Configuration -> Tweak Settings. Make sure Proxy subdomains is turned ON. Make sure Thunderbird and Outlook autodiscover and autoconfig support are turned OFF.
The second/manual fix (courtesy of comment at 2/14/2015 10:21 AM at http://community.office365.com/en-us/f/156/t/293985.aspx):
- Log in as root on your web server
- Edit /etc/httpd/conf/httpd.conf
- Search for autodiscover, you should find a ScriptAlias line referencing it
- Comment this line out or remove it completely
- Edit /usr/local/cpanel/APACHE_CONFIG and find the same line and remove it or comment it out
- on BlueHost, run "/usr/local/cpanel/bin/apache_conf_distiller --update"
- run "service httpd graceful" to restart apache
Afterwards, test your autodiscover via https://testconnectivity.microsoft.com and presuming a successful tests - all is well since the web server is no longer responding to autodiscover requests.
Monday, March 16, 2015
Superfetch causes 100% disk usage on Windows 8 machines
I was working on a Samsung laptop with Windows 8.1 where the machine's performance was subpar and I found that Task Manager shows disk usage was 100% (CPU and memory usage were normal). When I opened resource monitor, I didn't see any programs using any more disk than normal. Mostly from this page:
http://www.tomshardware.com/answers/id-2045646/windows-100-disk-usage.html
I decided to disable superfetch, which worked for me. Disk usage dropped to single digits and would rise to 100% if/when the superfetech service was re-enabled.
http://www.tomshardware.com/answers/id-2045646/windows-100-disk-usage.html
I decided to disable superfetch, which worked for me. Disk usage dropped to single digits and would rise to 100% if/when the superfetech service was re-enabled.
Labels:
100%,
8.1,
disk usage,
service,
services,
services.msc,
superfetch,
windows 8
Wednesday, March 4, 2015
using rsop.msc to check group policies applied to a domain machine
In troubleshooting another problem, I came across a suggestion to run rsop.msc on the client machine. Rsop.msc displays all the group policies that are applied to a domain machine. In my case, it helped me track down a group policy that was forcing machines on the domain to never go to sleep. I guess that policy makes sense with desktops, but a particular user did not want this behavior on his laptop.
Anyway, rsop.msc made this much easier and is a tool I'll keep in mind.
Anyway, rsop.msc made this much easier and is a tool I'll keep in mind.
Labels:
group policy,
policy,
power settings,
rsop,
rsop.msc,
sleep
Subscribe to:
Posts (Atom)