About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. The opinions expressed on this blog are mine and mine alone.

2011/05/25

Lync Server 2010 Backup

Published up on Microsoft Download, we now have some official word on backup and restore for Lync Server.  Quoted from DrRez:

This document describes a methodology for backing up and restoring the data that is required for full recovery of Microsoft Lync Server 2010 services. It includes the procedures for backing up data and recovering from the following levels of failure: Standard Edition Server, Central Management Server, Enterprise Edition Back End Server, a server that is a member of any Lync Server pool, a Lync Server pool, a File Store, an Archiving Server or a Monitoring Server with a collocated database, and a stand-alone Archiving database or Monitoring database.

Visit Backing Up and Restoring Lync Server 2010 to download the whitepaper.

2011/05/17

Download Silverlight v4

My client does not allow the Lync FE servers to reach the internet directly on 80 or 443.  Therefore I needed to find a download of Silverlight for the Lync Control Panel.

Here it is.

2011/05/11

AntiVirus and Lync

Right from the online CHM file entry on virus scanning exclusions.  I had a bit of trouble finding this, even though I knew it was there.  A colleague reminded me of this, so I thought I would throw up a quick reference so I can always find it.  I had a client ask me this question, and my response was “the entire install structure, the standard SQL exclusions, and the file share location.

Here is the link to the official material, and below is the data copied from that link so I don’t have to go hunting for it!  Note that the Lync file share is not on this list; however, I have seen some issues with meeting content when the server is actively scanning that location.  I cannot say for certain that the virus scanning on the server was causing the issue, but I do know that disabling the virus program on the server fixed the issue.  On the client side, it appears that some client virus engines get in the way of certain Lync functions unless you specifically add the Communicator.exe program to the engine’s allowed programs.

Specifying Anti-Virus Scanning Exclusions

To ensure that the antivirus scanner does not interfere with the operation of Microsoft Lync Server 2010, you must exclude specific processes and directories for each Lync Server 2010 server or server role on which you run an antivirus scanner. The following processes and directories should be excluded:

  • Lync Server 2010 processes:
    • ASMCUSvc.exe
    • AVMCUSvc.exe
    • DataMCUSvc.exe
    • DataProxy.exe
    • FileTransferAgent.exe
    • IMMCUSvc.exe
    • MasterReplicatorAgent.exe
    • MediaRelaySvc.exe
    • MediationServerSvc.exe
    • MeetingMCUSvc.exe
    • MRASSvc.exe
    • OcsAppServerHost.exe
    • QmsSvc.exe
    • ReplicaReplicatorAgent.exe
    • RTCArch.exe
    • RtcCdr.exe
    • RTCSrv.exe
    IIS processes:
    • %systemroot%\system32\inetsrv\w3wp.exe
    • %systemroot%\SysWOW64\inetsrv\w3wp.exe
  • SQL Server processes:
    • %ProgramFiles%\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn\SQLServr.exe
    • %ProgramFiles%\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\Bin\ReportingServicesService.exe
    • %ProgramFiles%\Microsoft SQL Server\MSAS10.MSSQLSERVER\OLAP\Bin\MSMDSrv.exe
  • Directories:
    • %systemroot%\System32\LogFiles
    • %systemroot%\SysWow64\LogFiles

2011/05/04

dot net v4 breaks iSCSI from NetApp v6.3sp2

 

edit 15 May 2011

Some feedback from NetApp is that this will work *IF* the SDW and NET3.51 are installed first before putting NET 4 into place.

---

In our environment, .net v4 also appeared to block installation of BES 5.0.3.  My support chain contacted NetApp engineering, who says that .net v4 is supported.

FWIW, we are using Server 2008 R2 SP1, with all updates (straight install), VMware ESX and ESXi v4, UCS hardware.  I do not know the NetApp filer model/version.

What we saw:  after install of the base O/S, we installed the NetApp v6.3sp2 LUN driver.  Everything appeared to work failry well, until we committed to the LUN and the connection process started.  All we ever got was the 120 second time out.  On the back end, the LUN looked connected at the NetApp, but on the server, there was nothing.  Attempts to reconnect at that point resulted in being told that LUN was already dedicated.

Removing .net 4 components from the server allowed full, normal, LUN connection.

 

YMMV

2011/04/28

E2010 sp1 cannot close EMC

Just installed e2010 with SP1  - CAS/HT server.  EMC will not close.  Seems to be an IE9 issue, with mixed reporting of not having the issue and having the issue.  If you have the issue, the fix appears to be uninstalling IE9.  Of course, with the way IE is linked into the O/S, this route may result in other issues.

See this thread for some background.

In my case, simply rebooting the server as a post-install action cleared the issue.

YMMV.

2011/04/27

Server 2008 R2 SP1 AD errors

At a customer site doing some due diligence on AD health.  DCDiag from the first Exchange 2010 CAS server against the FSMO holder failed on the DFRSEvent and KCCEvent checks with an event ID of 0x6BA.  Running the same test on the FSMO holder (we need to extend the schema folks!) failed with 0x6BA also. 

Once we got the first issue reduced, then another popped up on both the FSMO holder and the DCDiag from the Exchange CAS server:  0x8000043B

Doing a little googling revealed this blog entry that got me started on fixing the issue. However, this blog entry clearly stated that the “Remote Service Management (RPC)” was the culprit. 

image

Enabling this rule in the DC’s firewall did not help me; so I started with all the rest that looked like they might be what I was looking for.  Not the most scientific method, but my reasoning was that it was better than turning the FW off entirely.  Also, all other data I could find for this issue all pointed back to the one blog – that guy should be charging for plagiarism!  For my situation, we had to enable this other rule also:  “Remote Administration (RPC)” as shown. 

image

At this point, DCDiag /s:fsmohost completed so quickly you would have thought the entire thing errored out.  Instead, what it did was pitch the KCCEvent event ID:  0x8000043B.  Not good, I still need the FSMO holder to behave so I can extend the schema (amongst other tasks…).  After wading through more googles, the fix to this second layer of error was:

dcdiag /fix

wala!  Nice clean dcdiag runs from both the FSMO holder and the exchange servers. 

test 02 Feb

this is a test it’s only a test this should be a picture