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.
Monday, December 9, 2013
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.
Tuesday, February 19, 2013
Clearing an Error on Microsoft Lync 2010 published on Citrix XenApp
Let me preface this post with saying: running Office Communicator or Lync on Citrix is not ideal. Why? It's a presence application. Unless you're working directly in OCS or the Lync client, your session on the XenApp server is idle, there fore your 'available' or 'idle/away' indicators may be inaccurate.
That being said, it can be handy to have your IM client readily available on Citrix.
I had been running Office Communicator 2007 R2 successfully, but Lync 2010 was giving me error messages:
"Either there is no default mail client or the current mail client cannot fulfill the messaging request. Please run Microsoft Office Outlook and set it as the default mail client."
I had installed Outlook 2010 and launched it, checked the default mail client, all to no avail.
The problem? I had actually published the wrong exe.
This Citrix forum post tipped me off to the mistake. The correct application? "C:\Program Files (x86)\Microsoft Lync\communicator.exe"
http://forums.citrix.com/thread.jspa?messageID=1715879
That being said, it can be handy to have your IM client readily available on Citrix.
I had been running Office Communicator 2007 R2 successfully, but Lync 2010 was giving me error messages:
"Either there is no default mail client or the current mail client cannot fulfill the messaging request. Please run Microsoft Office Outlook and set it as the default mail client."
I had installed Outlook 2010 and launched it, checked the default mail client, all to no avail.
The problem? I had actually published the wrong exe.
This Citrix forum post tipped me off to the mistake. The correct application? "C:\Program Files (x86)\Microsoft Lync\communicator.exe"
http://forums.citrix.com/thread.jspa?messageID=1715879
Thursday, February 7, 2013
Dell Servers, clearing the amber light
I run an environment consisting of Dell servers. I'm quite happy with them. They have some good management and monitoring utilities, and they've greatly improved applying things like firmware updates over the years.
This one was easy, but Googling didn't get me the answer, so I figured it warranted a post.
I had dealt with a nasty disk issue previously. In the end, I recovered the server to health, but my original RAID1 running in drives 0 and 1 had to reconfigured to run from drive 1 and drive 7 as a global hot spare. It seemed that there was a hardware problem in slot 0, and as the server is nearing retirement, it was easier just to leave drive 0 empty.
Some weeks later, someone else pointed out the "amber light." I monitor my systems through OMSE (Open Manage Server Essentials) which relies on OMSA (Open Manage Server Administrator), and the server showed healthy.
Physical examination yielded "PowerEdge 2950 E1812 HDD 0 Removed." Well, that was true, but I didn't need to see an amber light for it.
Going online netted me results like "Clear SEL" without telling me how to do that.
The quick and easy solution: clearing the hardware log.
From the OMSA web interface, from System, select Logs, and then Hardware. Then Clear Log.
Voila. Healthy blue display screen, no amber light.
This one was easy, but Googling didn't get me the answer, so I figured it warranted a post.
I had dealt with a nasty disk issue previously. In the end, I recovered the server to health, but my original RAID1 running in drives 0 and 1 had to reconfigured to run from drive 1 and drive 7 as a global hot spare. It seemed that there was a hardware problem in slot 0, and as the server is nearing retirement, it was easier just to leave drive 0 empty.
Some weeks later, someone else pointed out the "amber light." I monitor my systems through OMSE (Open Manage Server Essentials) which relies on OMSA (Open Manage Server Administrator), and the server showed healthy.
Physical examination yielded "PowerEdge 2950 E1812 HDD 0 Removed." Well, that was true, but I didn't need to see an amber light for it.
Going online netted me results like "Clear SEL" without telling me how to do that.
The quick and easy solution: clearing the hardware log.
From the OMSA web interface, from System, select Logs, and then Hardware. Then Clear Log.
Voila. Healthy blue display screen, no amber light.
Subscribe to:
Posts (Atom)