At work, I upgraded my laptop by replacing the hard drive with an SSD. Boy, did it make a nice improvement in performance. I took the purist approach and did a fresh install of Windows 7 and reinstalled all my applications.
Imagine my chagrin after a careful rebuild, only to find a number of DLL files in the root of my C drive. I deleted them, only to find them returning regularly.
Doing some Googling on one of the DLL names (such as tsgetxu6ag55.dll) wasn't turning up good results. I'd find lots of results to web sites that 'identify files' and would give me a lot of nonsense answers not clearly telling me if it was spyware, a legitimate file, or any useful info.
I stumbled onto what was going on once I started Googling what the file was. The properties of the DLL made mention of Tom Sawyer. Once I Googled that, lo and behold the answer came to light.
https://thwack.solarwinds.com/thread/55808
One piece of software I had reinstalled was SolarWinds IP Address Tracker. The newer version apparently isn't well-written, and it dumps many files in the root of your C drive. Well, that's helpful (NOT).
At that point, I searched and found an older version of the install and downloaded that. No more pesky DLLs appearing in the root of my C drive.
Friday, November 7, 2014
Wednesday, April 16, 2014
Unable to Sign In on Google Chrome to Office 365
My organization has been moving from hosting our own Exchange and Lync/Office Communications on premise to Microsoft hosted via Office 365.
I had implemented Active Directory Federation Services (ADFS) and Lync Online about 18 months ago. ADFS had some challenges, but once I implemented it, it has been reliable. During implementation, I got on-premise pass through Windows Authentication working and off-premise sign in working. I had tested on versions of Internet Explorer, Mozilla Firefox, and Google Chrome successfully.
We're now readying to migrate to Exchange Online and away from our on-premise mail server. During testing, several of us in IT began realizing that sign-ins from Google Chrome was not working.
On premise, you would be prompted with a Google Chrome pop up dialog. You'd put in your credentials (email address and Active Directory password), and it'd take you right back to the logon prompt without error, and you'd never get in.
Off premise, you would be directed to our sign in page on our Federated Server Proxy server. Same behavior, enter credentials, return right back to sign in page without error.
Googling this error tipped me off to the problem being that Google Chrome not supporting Extended Protection. But I didn't know much about this, so I didn't know how to resolve the issue.
A case opened with Microsoft support got me directed to the fix, as documented here:
http://social.technet.microsoft.com/wiki/contents/articles/1426.ad-fs-2-0-continuously-prompted-for-credentials-while-using-fiddler-web-debugger.aspx
The article mentions problems when using Fiddler Web Debugger, but it's the fix for a Google Chrome issue as well.
It's a setting within IIS. The above link documents where the setting is within IIS to change it manually on each affected server (typically you have multiple ADFS servers for fault tolerance), or PowerShell commands to set this universally across the farm.
Once I made this change, my users can leverage Office 365 from any of the major browsers.
I had implemented Active Directory Federation Services (ADFS) and Lync Online about 18 months ago. ADFS had some challenges, but once I implemented it, it has been reliable. During implementation, I got on-premise pass through Windows Authentication working and off-premise sign in working. I had tested on versions of Internet Explorer, Mozilla Firefox, and Google Chrome successfully.
We're now readying to migrate to Exchange Online and away from our on-premise mail server. During testing, several of us in IT began realizing that sign-ins from Google Chrome was not working.
On premise, you would be prompted with a Google Chrome pop up dialog. You'd put in your credentials (email address and Active Directory password), and it'd take you right back to the logon prompt without error, and you'd never get in.
Off premise, you would be directed to our sign in page on our Federated Server Proxy server. Same behavior, enter credentials, return right back to sign in page without error.
Googling this error tipped me off to the problem being that Google Chrome not supporting Extended Protection. But I didn't know much about this, so I didn't know how to resolve the issue.
A case opened with Microsoft support got me directed to the fix, as documented here:
http://social.technet.microsoft.com/wiki/contents/articles/1426.ad-fs-2-0-continuously-prompted-for-credentials-while-using-fiddler-web-debugger.aspx
The article mentions problems when using Fiddler Web Debugger, but it's the fix for a Google Chrome issue as well.
It's a setting within IIS. The above link documents where the setting is within IIS to change it manually on each affected server (typically you have multiple ADFS servers for fault tolerance), or PowerShell commands to set this universally across the farm.
Once I made this change, my users can leverage Office 365 from any of the major browsers.
Monday, December 9, 2013
Connecting with Lync on Mac via Office 365
My organization transitioned from running Office Communications Server 2007 to Lync via Office 365. One of the benefits of the Office 365 implementation is that you can run applications like Lync while properly on the corporate network or while remote with Internet access.
Though our organization is strictly a Windows computing environment, there are a few people within the IT department that run Macs at home. As I was one of them, I wanted to explore running Lync on Mac OSX 10.9 Mavericks.
I downloaded Lync for Mac 2011, but was having difficulty signing in.
Investigating online, I found this article:
http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh534388.aspx
But still, things weren't working:
A support call to Microsoft didn't yield the answer at all. I assumed it was a very minor detail, and that was correct. After days of nothing, I stumbled across the correct configuration.
Ensure you've got all the updates downloaded for Lync / Office 2011 for Mac.
Correct syntax for sign in is to use your email address in both the email address AND user ID fields. I was trying username or domain\username and getting no results.
In the Advanced options, you want Use Kerberos authentication unchecked, and the radio button to use Automatic Configuration, as shown below:
At that point, you'll be able to sign in.
Though our organization is strictly a Windows computing environment, there are a few people within the IT department that run Macs at home. As I was one of them, I wanted to explore running Lync on Mac OSX 10.9 Mavericks.
I downloaded Lync for Mac 2011, but was having difficulty signing in.
Investigating online, I found this article:
http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh534388.aspx
But still, things weren't working:
A support call to Microsoft didn't yield the answer at all. I assumed it was a very minor detail, and that was correct. After days of nothing, I stumbled across the correct configuration.
Ensure you've got all the updates downloaded for Lync / Office 2011 for Mac.
Correct syntax for sign in is to use your email address in both the email address AND user ID fields. I was trying username or domain\username and getting no results.
In the Advanced options, you want Use Kerberos authentication unchecked, and the radio button to use Automatic Configuration, as shown below:
At that point, you'll be able to sign in.
Wednesday, June 26, 2013
Dell OpenManage Server Administrator + ESX5.0i update 2 = FAIL
I'm currently working on a new VMware ESX5.0i update 2 cluster. After the install of ESX5.0i, I set about to get OMSA on my hosts for health monitoring through OpenManage Server Essentials.
My initial efforts yielded me errors on the attempt to install. I was getting 'Could not find a trusted signer.' Googling this error led me here: http://charlieferreira.blogspot.com/2013/05/update-dell-openmanage-72-on-esxi5.html where they recommended adding the --no-sig-check flag.
That just changed my error. The install was then failing:
[VIBDownloadError]
Failed to download VIB.
url = vmware-fdm-5.0.0-623373
localfile = Unable to download VIB from any of the URLs
Please refer to the log file for more details.
/var/log/vmware # Unable to download VIB from any of the URLs
~sh: Unable: not found
At that point, I decided to get on the phone with Dell.
The verdict? OMSA doesn't have a version that supports 5.0 update 2. As this was released December 2012, and we're almost in July 2013, that was disappointing. I have to say I've been really unhappy with the poor health monitoring on ESX5i via Dell. I've had to implement service restarts automated on my hosts to keep the Dell software quasi-running (I still get bogus OMSE alerts that I have issues on the hosts that are not true).
Luckily for me, I have an enterprise iDRAC on the host that I can monitor over the OMSA software. If you didn't have that, I guess you'd be out of luck.
My initial efforts yielded me errors on the attempt to install. I was getting 'Could not find a trusted signer.' Googling this error led me here: http://charlieferreira.blogspot.com/2013/05/update-dell-openmanage-72-on-esxi5.html where they recommended adding the --no-sig-check flag.
That just changed my error. The install was then failing:
[VIBDownloadError]
Failed to download VIB.
url = vmware-fdm-5.0.0-623373
localfile = Unable to download VIB from any of the URLs
Please refer to the log file for more details.
/var/log/vmware # Unable to download VIB from any of the URLs
~sh: Unable: not found
At that point, I decided to get on the phone with Dell.
The verdict? OMSA doesn't have a version that supports 5.0 update 2. As this was released December 2012, and we're almost in July 2013, that was disappointing. I have to say I've been really unhappy with the poor health monitoring on ESX5i via Dell. I've had to implement service restarts automated on my hosts to keep the Dell software quasi-running (I still get bogus OMSE alerts that I have issues on the hosts that are not true).
Luckily for me, I have an enterprise iDRAC on the host that I can monitor over the OMSA software. If you didn't have that, I guess you'd be out of luck.
Subscribe to:
Posts (Atom)