You need to create a Certificate Signing Request (CSR) for your TMG to support Lync (or Exchange or whatever) - AND you need this certificate to have SAN (Subject Alternative Name) entries.
Chad McGreanor has a great write-up on this!
If you do not already have a Local Computer Certificates\Personal\Certificates container in your TMG deployment, you can still use this process – by accessing the CSR process as shown here:
YMMV
You have recently updated Lync Server 2010 to the latest Cumulative Update and you are having issues that appear to be DB related.
It is entirely likely that you may have missed updating your databases as required. This used to be a separate download. Now that the lyncserverupdateinstaller.exe is available (see this MS KB) I have noticed that sometimes people forget to update the databases which is a separate step.
AFTER you run the lyncserverupdateinstaller (remembering to do outside in methodology), here is what you need to do, by type of database environment:
If Enterprise Edition Back End Server databases are not collocated with any other databases, such as Archiving or Monitoring databases, at the command line, type the following:
Install-CsDatabase –Update –ConfiguredDatabases –SqlServerFqdn <SQL Server FQDN>
If Enterprise Edition Back End Server databases are collocated with other databases, such as Archiving or Monitoring databases, at the command line, type the following:
Install-CsDatabase –Update –ConfiguredDatabases –SqlServerFqdn <SQL Server FQDN> -ExcludeCollocatedStores
For Standard Edition, type the following:
Install-CsDatabase –Update –LocalDatabases
YMMV
I just spent the last 3-4 hours doing this research for some random issues as listed below. What resulted was a pretty comprehensive Tshoot OAB/GAL issues outline. Thought I would share.
Issue is (seemingly) random users get created but never show in the GAL – no pattern.
Issue is (seemingly) random users cannot see all users in GAL – no pattern.
- If you create a brand new Outlook profile on a newly installed client with a newly created account, in cached mode, are you able to download a full OAB successfully (this happens automatically with a new OL profile).
o If yes, do you see the "missing" account ?
o If yes, then the OAB is the correct one, and is correctly being updated.
- If no, you have a problem with syncing your OAB. It should point only to the GAL and if it does, and there are no sync errors, it MUST contain the errant account if this appears correctly in the GAL.
The answer to the short experiment above drives which of the following choices to pursue.
1. Can you see the Contact if you turn off Outlook Cached Mode?
2. Does the Contact resolve in Outlook Web Access?
3. Can others see the Contact?
4. Ensure that the user’s default external e-mail address and the windows e-mail address (AD attribute) are exactly the same.
5. If you have a client in cached mode that is not updating the OAB, remove/rename *.oab files in their %userprofile%\Local Settings\Application Data\Microsoft\Outlook. Next time you start Outlook it will re-download the address book and create new OAB files. The problem was the oab files got corrupt and would not catch new updates.
6. If it continues to happen, try excluding these oab files from your anti-virus scanner.
7. Recreate the users Outlook Profile and download all the content fresh
8. folder underneath OAB named d33d3462-etc-etc where the OAB resides had read only permissions set for authenticated users. The OAB folder did not have that permission.
9. On the e2010 server, make sure the Microsoft exchange file distribution service is running.
10. Make sure the recipient that does not show up has an x500 address entry
11. Does anything show in a BPA from e2003?
12. Does anything show in a BPA from e2010?
13. Which server is the OAB generator? Anything in the event log there?
14. Make an e2010 server the OAB generator
a. Any ol2003? Then you need PF distribution
b. Only OL2007 or higher? Use e2010 and web distribution
These seem fairly on point:
The domain controller that you are using for OAB gen specified in the 9117
event isn’t seeing that user. Make sure there is not a 9325 in the
application log skipping him because of a bad attribute. You can download a
copy of OABInteg from http://code.msdn.com/oabinteg. Use an online profile
and run oabinteg /s:srvname /t:proxytest /v:2 /l and look at the errors in
the log.
Try deleting the user's oab files then have him redownload.
Go to C:\Users\username\AppData\Local\Microsoft\Outlook
Delete all files with .oab
Outlook, send\receive download address book.
Also did you move this user to another new mailbox store? If so make sure the mailbox store has been set to use the default OAB.
Exchange 2007/2010 Web services and Autodiscover Ultimate Troubleshooting Guide
I decided to put this ultimate guide to spare the hustle and allow smoother and nicer web services experience.
Well, let us first list the directories that are used in the Exchange web service:
· EWS is used for OOF, Scheduling assistance and free+busy Lookup.
OAB provides offline address book download services for client.
Autodiscover is used to provide users with autodiscover service.
EAS provides ActiveSync services to Windows Mobile based devices.
OWA provides outlook web access for users.
ECP provides Exchange control panel feature for Exchange 2010 users only.
Issues that might be resolved using the troubleshooting steps here:
· You cannot set the OOF using outlook client, you receive the server not available error.
You cannot view free/busy information for other users.
You cannot use scheduling assistance, also you might receive not free/busy information data retrieved.
You cannot download Offline Address book errors.
You cannot use autodiscover externally.
Certificate mismatch error in autodiscover, users prompted to trust certificate in outlook 2007/2010.
I will update this post to include all of the errors that I face and solve in my work or on EE to help experts all over EE to quickly solve their issues.
First let us start by the configuration required post Exchange 2007/2010 installation for the above to work correctly:
Configure External and Internal URLs for OWS, ref: http://technet.microsoft.com/en-us/library/bb691323(EXCHG.80).aspx
· You have to configure the internal URL to be the server name in case you have multiple servers in NLB.
External URL will be the URL used by users to access webmail e.g. https://mail.domain.com/owa
Mail.domain.com in multiple CAS servers will be the NLB FQDN.
Configure External and Internal URLs for OAB, ref: http://technet.microsoft.com/en-us/library/bb123710.aspx
This will point if multiple CAS servers are used then this will point to NLB FQDN.
If single server used this will point to the internal server FQDN in the internal URL, and the mail.domain.com which is used by webmail users.
Configure the autodiscover internal URL:
· You will use the powershell cmdlet : Set-ClientAccessServer –Identity <CAS Server Name> -AutoDiscoverServiceInternalUri: <Internal URL>, this FQDN must match the URL included in the certificate.
If you cannot use autodiscover.domain.com internally (you have a domain name of domain.local and you must use it), you will get a certificate miss match error, you will have to include the internal name in the certificate if you purchase an external certificate.
If you have multiple CAS in NLB this will be the NLB FQDN.
You cannot set autodiscover external URL since outlook will try to access https://autodiscover.domain.com/autodiscover/autodiscover.xml, this behavior is by design and cannot be changed.
Autodiscover.domain.com must be included in the certificate that you assign to IIS if you purchasing a certificate externally from 3rd party provider.
Configure EAS internal and External URLs, ref: http://technet.microsoft.com/en-us/library/bb629533(EXCHG.80).aspx
· This URL will point to the NLB FQDN internally
This IRL will point to NLB FQDN Externally.
Configure the EWS (which provides availability, OOF) internal and external URLs
· You can set the internal FQDN and External FQDN using: get-webservicesvirtualdirectory | Set-WebServicesVirtualDirectory –InternalUrl: https://url.domain.local/EWS/Exchange.asmx –ExternalURl: https://url.domain.com/EWS/Exchange.asmx
after all of the above settings you have to take into considerations the following note:
· All of the above uses https connection, so SSL certificate must be configured and assigned to IIS on the CAS servers.
Since all of the above uses https, if you have a proxy traffic might be affected.
Make sure that clients can access the URL internally and externally, you can do that by going to the above URL using IE or Firefox and validate that you can access them.
For some people after doing the above configuration you still receive some errors so make sure of the following:
· IIS is started.
OWA application pool, OAB application pool and EWS application pool are running and started with no errors
If you receive authentication error, error 500 service not available, error 400 login time out, or unspecified error you will need to rebuild your virtual directories. You can do that as following:
· For OWA:
Get-owavirtualdirectory | remove-owavirtualdirectory
New-owavirtualdirectory.
You can repeat this step for EWS (webservicesdirectory), OAB (OABvirtualdirectory) and autodiscover(autodiscovervirtualdirectory)
You will have to note that you will need to re-configure any customizations you made to OWA after removing and deleting it, also you will have to redo any internal and external URL configuration you have did in the past
Troubleshooting Offline Address Book Generation on Exchange 2010
After migrating from Exchange 2007 to Exchange 2010, we began noticing that address book downloads failed during a manual send/receive operation with:
‘error (0x8004010F) operation failed. An object cannot be found.’
Basically, this error is happening because Outlook 2007 and higher clients rely on web based distribution of the offline address book, and that address book is not found on the CAS Server.
The fix is to enable the Default Offline Address book on the mailbox server for Web-based distribution:
This setting does not go into effect immediately. If you want to force it to start working immediately, you need to perform these steps:
1) Update the address book
2) Restart the File Distribution Service on the CAS Server
Performing this step will cause the CAS to download a copy of the OAB from the Mailbox server, see this post for more info on the Exchange File Distribution service.
3) Force Active Directory to sync (repadmin /syncall /APed)
Now, when you force a send/receive from Outlook, the address book will download cleanly!
There are other reasons why clients may be getting error 0x8004010F, check out this post for more information: http://blogs.msdn.com/dgoldman/archive/2008/10/01/understanding-why-error-code-0x8004010f-is-thrown-when-trying-to-download-an-oab.aspx
Also, if you are getting Event 9320 in your event logs, you can safely ignore those per this blog:
In November 2011, Microsoft released the mobility updates for Lync. Get the bits here. There is also a mobility guide on how to deploy, what needs to change, what stays the same, and what needs adding to your environment. Get the guide here.
Then just a few weeks ago, Microsoft released the actual clients. Windows 7.x mobile, of course, was available almost immediately, the Droid crowd got theirs quickly also. But iOS users had to wait for the AppStore to approve and release. And now they are here! To get your very own install, try the following links:
Once you have this wonderful tool installed, setup is very easy. Here is the initial screen:
Add the obvious information that is needed for autologin. You may need to add your account details if your AD login is different from your SIP address. If so, pull down the “more details” as shown. Also notice the toggle for “auto-detect.”
Then you enter your call back number. This is important because the Lync Mobility setup uses a server-centric call back routine much like the old COMO client did. You can make phone calls from the client, but the SERVER will call you, then call your other party. Works well.
Here is the options screen. Notice that everything is nice and clean. Well laid out and coherent. This is direct contrast to the Damaka Xync client that is clunky at best and confusing to use. Anyone familiar with Lync on the desktop will need no training to use this mobile client on iOS.
For those sharp-eyed readers, notice that I took all these screen shots from an iPad client. But the iPhone client is, as far as I can tell, exactly the same. Nice and consistent. Obviously, the iPad client benefits from a greatly expanded screen size, so all things are not exactly the same, but dang!
Also, because my iPhone is actually a phone with service (my iPad is not) the iPhone Lync client can be used to make phone calls as described above. The iPad client will join meetings, and when you initiate the call, the SERVER will call your cell phone (provided that is the number you entered in the setup). Nifty.
Here, I have entered a phone number and tapped on “call” – the system tells me to answer the call, which is the server connecting me.
Then, the server calls the other party…both sides think the server called them, which in fact it did. But now I can call clients using my cell phone, and having the call come from the office! Nice.
The iOS client has specific functionality – as outlined by the chart that you can find here. But the bottom line is that it works very well, and looks good to boot! Sadly (at least for my expectations) it will not do Audio, Video, or Desktop Sharing (like Xync – but Xync is a full edge client). To be fair, the other clients do not perform those functions either. A list of what CANNOT be done from the Lync iOS client:
) iOS clients can send location data in an IM. Very nice for tracking down your clients location or possibly showing your buddies what bar you are in….
Overall, I think this is solid release with some great functionality. The Damaka Xync client, as a full edge client, has full functionality. However, the Xync client has a strange interface and some things do not work quite as well I would like them to work; the Microsoft Lync Mobility client has a very clean interface that is instantly familiar – and it provides its’ feature set seamlessly. And free. Free is a very good price.
YMMV
Sitting in a car dealer getting my car fixed…. With my zippy new Verizon MiFi…not too shabby.
Over at cio.com, Sprint reveals how much it saved by deploying Lync Server. Discussion points cover why Sprint did it and where the savings are and several pain points are also highlighted.
Take a look here.
YMMV
Fellow MVP Stale Hansen has published a sweet Lync Server 2010 Troubleshooting Tips article.
Take a look here. I think you will find it extremely useful.
YMMV
When reviewing troubleshooting traces from both server roles and client side log files, you will encounter numerous SIP codes that may seem to be a complete different language.
Here is a nice MSDN guide to those SIP codes.
The guide is presented in terms of what the log file will reflect for various states and errors, whether they are unhandled or unidentified. Very helpful for those situations where things are just not operating as expected.
Client Error Display and Logic
YMMV
If you are deploying Lync Server 2010 with Exchange 2010 Unified Messaging, then this guide is your friend.
The sections of this document help you understand how to deploy and troubleshoot this vital UC component interaction to include conducting testst using synthetic transactions.
YMMV.
Maybe a tad esoteric…but if you need it you NEED it.
This document provides the necessary steps for installing the Communicator Mobile component alongside Lync Server 2010 so that Office Communicator Mobile 2007 R2 for Java and Office Communicator Mobile for Nokia 1.0 can connect to the Communicator Mobile component as usual, and the Communicator Mobile component can connect to Lync Server 2010.
YMMV
Patrick Kelly and Sebastiaan Poels just published a nice Lync Edge troubleshooting tips article.
YMMV
The ability to connect a mobile device to the Lync infrastructure is a feature that is missing (natively) from the Microsoft suite of Lync clients. We have been told that the mobile clients are “coming” but - nothing yet. Damaka.com publishes a line of Lync Server 2010 clients for mobile devices known as Xync. According to damaka, Xync is available for iOS, Android, and Symbian. Isn’t this a pretty picture?
Xync for iOS has my attention – you guessed it – I have an iPhone and an iPad. I would LOVE to have something to replace iDialogue and its’ need for an OCS CWA server. This article is a review of the Xync client, how it operates against my production Lync environment, how it interacts with my laptop (full Lync) client, and a run through of how the Xync client behaves in IM, video, and audio calls and conferencing.
Let's start with the Xync client itself. There are three (count ‘em!) versions. Xync, XyncConf, and XyncCollab. Actually, there are two more also, Xync-HD and XyncConf-HD. So, when faced with five different choices, which one do you want? I asked that very question to the fine folks at damaka, and after a (what I feel was a lengthy) delay, I got the following answer:
Take a look at this and observe that the prices go up as the features go up. I do not have understanding of the business logic that made up the delineation of the feature sets into three clients, but there it is. Also, note that the XyncCollab client (the one I purchased) is not marked as “+” (meaning both iPhone and iPad).
Why is there no HD version of XyncCollab? According to damaka’s Ramesh Chaturvedi, the XyncCollab-HD is coming and should be on the appstore soon (in approval process).
What are the differences between iPhone functionality and iPad functionality (xync and conf and hd) ? According to Mr. Chaturvedi, each is optimized for the intended platform. I used the XyncCollab on an iPad, and noticed some things that did not work as expected – such as following the screen orientation, and having that lovely 1x-2x button on the bottom right corner of the display. Using the 1x-2x button increased the view – and not too badly either. Resolution seemed to scale fairly well; not like some games and whatnot where the smaller screen resolution for the iPhone looks crappy (to put it mildly) when increased to 2x.
damaka claims to offer full functionality – full Lync/OCS client – no backend hardware/services required. As to the “no backend” part, I agree. Xync connected via our Edge just fine – in fact, it used the obvious route of discovering the SRV record and connecting. Here is the login screen.
The various data blocks are filled out like normal. Tapping the indicated icon will present you with the custom login screen. Notice the Office 365 option; pretty nice for a third party.
Back to our initial login screen…enter the necessary info, then tap the key icon.
Hola! We are in. I did nothing other than what I would do for my regular Lync client on my laptop, nor did my companies admin have to do anything to support my efforts. Notice that brought my contact list groups right in as expected.
The basic controls are (from left to right across the bottom), create a conference, create a voice conference, voice calls, active sessions, preferences, and sign out. I never did get the conference controls to work. Many times I would follow the “double tap” instructions only to have the client disappear from screen.
Very funky and strange. Sometimes the client crashed and sometimes it did not. When it did not crash, the client went down into the tray and I had to double the home key to go get it or choose Xync again from the desk(tablet)top. If this is why you want to use this tool, I would say it makes it a “no go.” Adelante.
IM worked well when I got that far. Choose a contact, and then the arrow icon on the right side.
From the next screen, you can choose your communication modality.
From left to right, IM, voice call, video call, and I will leave it to you to guess the purpose of the “x'” – although that is pretty obvious. One quirk I did notice here was that you can have one of each with each contact. So, opening an IM, a call, and video session results in three separate sessions with that contact. Not what I was expecting. But hey, lookee! File transfers worked!
Once you have an IM session open, hitting the drop down as shown gives you the modality choices again. But, then we had multiple sessions open at once. And if you do that, you need to know that there is swiping needed to go swipe left/right to page through the sessions. That took me a goodly bit of time to discover.
Voice calls worked well, as did video calling. On the iPad you can flip between the two cameras – so this makes your iPad a potential mobile conference room video source. Here is a nice shot of my hotel; pretty good video from the front iPad camera.
However, on the same vein, the initial video setup has your local video plunked right on top of the remote video. And it took me some frustrating time to figure out that I could swipe the local video and make it disappear. Other than troubleshooting, I don’t see a lot of value in the local video being the size it is, nor does it have much value – I know who I am and what I look like!
Video is h.263, Mr. Chaturvedi said that rtvideo is planned and coming.
Audio calls, using the interface given, turned my iPad into a telephone across the local wireless connection. Sweet!
Desktop Sharing also worked well, but only as a participant. I could not originate the DTS session. Once I had the share sent my direction, I could have control – so this is a partial win.
The User guide/manuals are on the damaka website. There is a goodly amount of help/information there.
I noticed that PIC contacts took a LOOOOOONG time to update presence. I never spent any time on this, but contacts which showed online in my Lync client would show as offline in Xync. Odd. Yet once I sent them an IM from Lync, the Xync updated their presence and then was willing to work with that contact.
Having my iPad be able to make and take phone calls based on the corporate PSTN structure was simply outstanding. Video calls ditto.
I noticed no method of location input – how does this translate to e9-1-1? Mr. Chaturvedi said that this feature is Not supported for location services at this time. If you need this for your deployment, then you may be out of luck until a further update.
I find the pricing a tad steep – but who else is providing this service for my device for my infrastructure?
Performance over hotel wireless (on both ends) was highly acceptable. Not perfect, but my assessment of the performance issues was that the wireless was the issue, not the iPad or the Xync client.
Licensing for individual v enterprise is available as is the possibility of using MDM on site to allow the corporate to control clients.
Finally, damaka has Xync data which can be found here:
http://xync.damaka.com and http://videos.damaka.com
I hope this helps you make your mobility client decision.
YMMV
E2007 migration to E2010. Client needs IMAP to work for some high-powered clientele – this thing really needs to be SSL also. E2007 is working as required, so E2010 should slam dunk this requirement, right? Wrong!
Using a CASArray, so I configured a Thunderbird to go right at a CAS; nope….no good.
Changed the CAS to plaintextlogin (set-imapsettings –logintype plaintextlogin) – still no go. Restarted services and spattered the sacred IT Chicken Blood on the nearest wall. We were also seeing weird results in password types – Thunderbird will “probe” the target server for you – which resulted in Kerberos/GSSAPI as the auth choice – no, that is wrong, we want SSL and regular text password. Double checked the e2007 server and determined that the e2010 IMAP was configured identically to the E2007.
Double checked that I had changed the IMAP SSL certificate on both CAS array members correctly… (Set-ImapSettings -server Server01 -X509CertificateName CertificateName01) - You do know about the x509 and IMAP SSL thing, right?
I just wasted 3 hours of my life over this….
Then this was found on the forums…You must be kidding me! So here is what fixed my issue:
Open the file at
C:\program files\Microsoft\Exchange Server\V14\ClientAccess\PopImap\Microsoft.Exchange.Imap4.exe.config
I went to bottom of the <dependentAssembly> as shown here:
And inserted what was indicated. Note that I have four lines of additions there, so what you see below is wrapped. However, I have also cleverly given you an example to follow. How thoughtful of me, eh?
<dependentAssembly>
<assemblyIdentity name="Microsoft.Exchange.Compliance" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<codeBase version="14.0.0.0" href="file:///C:\Program Files\Microsoft\Exchange Server\V14\bin\Microsoft.Exchange.Compliance.dll" />
</dependentAssembly>
After restarting the IMAP service on the CAS, everything worked ok. Changed IMAP back to “SecureLogin” – still good.
Now, I did not try the POP fix as that was not needed for my client environment…
YMMV
First off, you would think the ExBPA would be smart enough to recognize this situation and not behave this way, but that is a subject for another post.
The E2010 Exchange Best Practice Analyzer (ExBPA) throws the following error when run against a new E2010 install. The environment originally came from E2003, then moved to E2007, now moving to E2010. The E2003 was removed 18 months or so ago…
This link from the ExBPA gives some great information provided you are still running E2003. If you are not, what to do?
There are a variety of resources in google-land that will advise you to just ignore the errors messages. As an example, here is one with an Exchange MVP advising against doing some drastic like removing whole containers from the configuration. Sembee gives great advice. But what if you don’t like seeing those Red X notices? What if your boss does not like them and judges you accordingly? Let’s see if we can do something non-invasive to remove this specific error.
Read the first link above, and then attempt to digest this part of it:
The Microsoft Exchange Server Analyzer Tool queries the Active Directory directory service to determine the value of the msExchAddressListServiceLink attribute for each Recipient Update Service object in the directory. The msExchAddressListServiceLink attribute is a link from the address list service to the Exchange Server computer it should be running on. If the Exchange Analyzer finds that there is no msExchAddressListServiceLink attribute for a Recipient Update Service object, or the msExchAddressListServiceLink attribute value for the object is not populated, an error is displayed.
How does this translate into reality? From an ADSIedit viewpoint, we can see the RUS container is very much still in AD (the reference environment came from E2003). In this view, I am showing the actual attribute on the domain RUS object.
So, this is why the ExBPA is pitching the error. What do we put in there to remove the error. Well, the name of an Exchange server of course! But what format and where can I get it?
Here is the format:
CN=E2010,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=domain,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
And here is where you can get this wonderful data string:
Plug this into the attribute of the RUS object as shown:
Depending on which DC/GC you are talking to with what server, wait 15 minutes or so for replication to occur, then re-run ExBPA. The RUS error will now be gone. Please note that this is visual only, E2010 ignores the RUS containers as RUS no longer exists in E2010 (E2007 for that matter).
This is NOT a supported fix. I suppose if you are still running E2003 and get this error, you could use this to resolve that instance as it illustrates the guidance of the recommended fix.
The Fix #2 (Supported)
After doing a bit more research, and reviewing exactly how to remove E2003, I realized that removing the RUS is part of the process:
Perform the following steps to delete the domain Recipient Update Services:
You will not be able to delete the Recipient Update Service (Enterprise Configuration) by using Exchange 2003 or Exchange 2000 System Manager. Perform the following steps to delete the Recipient Update Service (Enterprise Configuration) by using ADSI Edit (AdsiEdit.msc):
YMMV
Discovered that the ExBPA pitches an error if the servers container is missing. D’oh! Makes sense, sorta. So I recreated the servers container in the First Administrative Group, with only the right type of container and name “Servers” – and that got rid of the error AANNDD the Exfolders access to the E2007 PF still works. Nifty, eh?
While in the midst of an upgrade to to 2010, we noticed that PF replication was bombing, ExFolders would not connect to the E2007 MBX – it threw a “recipient cannot be found” error - and we were getting sporadic weirdness with the AddReplicaToPFRecursive.ps1 script. We are using E2010 SP1 RU5.
Odd.
The client had previously removed Exchange 2003 in favor of Exchange 2007 some 18 months or so ago. Exchange 2003 was removed and roles transferred, but the server was never uninstalled. This left some remnants behind, as you would expect. The server was removed from AD with ADSIEdit as part of an AD cleanup prior to deploying E2010.
A little light reading here and then we followed the obvious indication to remove the empty “servers” container from the “First Administration Group” left over from Exchange 2003. DO NOT remove the entire “First Administration Group” container, or any others left over from legacy versions.
Wala! At least this was an easy one. This was supposedly fixed with E2010 SP1 RU5, but apparently not.
YMMV
I ran into a very odd situation today. Now, I know that there are those out there in cyberland who will have seen this before, but I have not, and on the odd chance that it might help you, I post this.
Doing WNLB, using VMWare hosting the WNLB servers. Therefore, according to VMWare we should be using multicast. So we did. And swiftly noticed that other servers on the local VLAN could not find the WNLB address. In fact, we noticed that the switch itself could not ping the WNLB address. Devices on OTHER vlans could ping the WNLB. WTF?! Double-check the setup and redo the static ARP on the switch with this:
ARP 10.1.8.75 03bf.c0a8.0164 ARPA
Here is what it looked like AFTER we did the proper static ARP configuration on the switch…
Notice that a tracert is showing that even the simplest action is pushing the packets at the local gateway.
We are using the following switch hardware:
Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500-ENTSERVICESK9-M), Version 12.2(54)SG, RELEASE SOFTWARE (fc3)
System image file is "bootflash:cat4500-entservicesk9-mz.122-54.SG.bin"
cisco WS-C4948-10GE (MPC8540) processor (revision 5) with 262144K bytes of memory.
Processor board ID FOX092101VW
After going back and forth, including rebuilding the WNLB configuration, we realized we were dealing with a multicast capable switch. Having nothing to lose, we did the following on the switch:
no ip multicast-routing
wala! Now we can resolve the WNLB, ping it, tracert to it, and actually access services on the member servers. Oddly, I had a colleague with a similar issue at the same time. Their situation was resolved by using the arp IP MAC arpa command not only on the switch the WNLB connected to, but all distribution switches and the core of the stack also.
YMMV
Thanks to Elan Shudnow and Bob Wille who helped get to the bottom of this.
At a client site the other day, my Lync client pitched the following error:
Now, as you might imagine, the name here does not match what my client was expecting to find. Clicking on “connect” fails with this error:
Using the “Try Another Server” allows my client to connect normally; closing the error message with the upper right corner red ‘x’ allows my client to connect normally.
What is going on here? The Lync client does a number of automatic lookups when initiating login so it can locate an appropriate server. Here we can see my client querying the local DNS to find its’ server, and we can also see the client ASKING for the address for the lyncfrontendvip that is causing this error.
What is causing this behavior? Handled correctly, this is not stopping my client from connecting (eventually); however, this is certainly unexpected. So, here is a netmon trace of my client but this time from another location (my hotel). Note the Lync client is no longer requesting the odd vipname address.
As it turns out, my client’s environment/site location is configured for Lync Phone Edition support; this means that DHCP option 120 was created and configured to deliver information necessary for allowing proper Lync Phone operations. This screen cap shows this DHCP delivery; and here is the vipname being delivered to my Lync client.
What is happening is that the DHCP, configured for Lync Phone support, is delivering (as it should) SIPServer data to the client host machine. Clearly, Lync client is hardcoded to default to the SIPServer definition address if that DNS query is valid. Hence, inside my client’s environment, my Lync client was delivered a SIPServer definition, and used it in favor of the expected _sipexternaltls._tcp.domain.com. When it attached to the defined SIPServer, it then failed to login (duh!) because my account did not exist on that system. Cancelling the dialogue or telling the client to try another server works because Lync then tries the existing returns for _sipexternaltls._tcp.domain.com.
Consultants who are working in a Lync Phone enabled client environment may see this Lync behavior. However, your regular users who are roaming, visiting THEIR client sites might see this also. Their solution, if they don’t figure it out for themselves will be to cancel the error dialogue. Your job will be to explain the whole mess to them. I hope this helps.
YMMV.
Recently, I had to migrate/move users from E2003 to E2010 cross-forest. FIM took care of the basic user objects (MEU’s) in the new forest, so I developed the following. It would seem that this process, while hinted at in various websites, blogs, and articles, was always sort of vague – and in my case the permissions referenced were not enough to complete the tasks. The source object modifications failed. As I was doing the moves with a domain admin/org admin in the target, I had no issues there.
csv format
# remember to not have a trailing line feed after the last entry
# - it causes the script to loop on a blank line
# - you can also remove the database field and e2010 will distribute mailboxes automatically among the available databases
---
identity,database
%m@domain.com,databasename
%m@domain.com,databasename
---
Perms needed
# The various texts indicate much less perms (recipient admin and local admin to the server) than I show here.
# These work much better!
Target: Domain Admin and Exchange Org Administrator
Source: Domain Admin and e2003 Full Admin
--- script follows ---
$SourceCredentials = Get-Credential
$TargetCredentials = Get-Credential
set-location "D:\program files\microsoft\exchange server\v14\Scripts"
import-csv d:\migrationcsvfiles\testusers.csv | foreach {.\Prepare-MoveRequest.ps1 -Identity $_.identity -RemoteForestDomainController whateveritis.domain.com -RemoteForestCredential $sourceCredentials -LocalForestDomainController whateveritis.domain.com -LocalForestCredential $targetCredentials -UseLocalObject}
# I noticed some random AD GUID errors when running both lines at once, so I started the top four lines, then did not copy in the line return after the new-moverequest and things stop erroring. YMMV.
import-csv d:\migrationcsvfiles\testusers.csv | foreach {New-MoveRequest -Identity $_.identity -RemoteLegacy -TargetDatabase $_.database -RemoteGlobalCatalog whateveritis.domain.com -RemoteCredential $sourceCredentials -DomainController whateveritis.domain.com -TargetDeliveryDomain "domain.com"}
---
Actions in the EMC such as moving active databases or any command that modifies an object are successful, but complete with a warning message:
Warning:
The cmdlet extension agent with the index 0 has thrown an exception in OnComplete(). The exception is: System.Net.WebException: The request failed with HTTP status 404: Not Found.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at Microsoft.Exchange.SoapWebClient.CustomSoapHttpClientProtocol.<>c__DisplayClass4.<Invoke>b__3()
at Microsoft.Exchange.SoapWebClient.HttpAuthenticator.NetworkServiceHttpAuthenticator.AuthenticateAndExecute[T](SoapHttpClientProtocol client, AuthenticateAndExecuteHandler`1 handler)
at Microsoft.Exchange.SoapWebClient.SoapHttpClientAuthenticator.AuthenticateAndExecute[T](SoapHttpClientProtocol client, AuthenticateAndExecuteHandler`1 handler)
at Microsoft.Exchange.SoapWebClient.EWS.ExchangeServiceBinding.FindFolder(FindFolderType FindFolder1)
at Microsoft.Exchange.ProvisioningAgent.MailboxLoggerFactory.EwsMailer.GetAdminAuditLogsFolder(ADUser adUser)
at Microsoft.Exchange.ProvisioningAgent.MailboxLoggerFactory.EwsMailer..ctor(OrganizationId organizationId, ADUser adUser, ExchangePrincipal principal)
at Microsoft.Exchange.ProvisioningAgent.MailboxLoggerFactory.Create(OrganizationId organizationId, ADUser mailbox, ExchangePrincipal principal)
at Microsoft.Exchange.ProvisioningAgent.AdminLogAgentClassFactory.ConfigWrapper.get_MailboxLogger()
at Microsoft.Exchange.ProvisioningAgent.AdminLogProvisioningHandler.OnComplete(Boolean succeeded, Exception e)
at Microsoft.Exchange.Provisioning.ProvisioningLayer.OnComplete(Task task, Boolean succeeded, Exception exception)
This is, of course very annoying and looks pretty bad. After some googling, I found this blog.
While not exactly accurate to my situation (my EWS is configured properly) I figured it could not hurt to try.
Get-AdminAuditLogConfig
Set-AdminAuditLogConfig -AdminAuditLogEnabled $false
These screen caps show that the adminaudit logging was indeed set to the Exchange 2010 SP1 default.; disabling this function makes the error warnings cease and the desired actions are s still successful. Because my EWS was configured properly, I believe the system is throwing the error because my EWS is already configured to support HLB that does not exist (yet). I will reverse this command after we deploy the HLB layer to confirm.
YMMV
Opened the EMC on several E2010 servers today. Was rudely told that the EMC could not contact the local server. A reboot fixed the problem, but I don’t like that.
I found this little routine here.
1. make sure IIS WinRM extension is installed
2. open powershell and run command : WinRM Quickconfig
3. Open IIS go to Powershell virtual directory and check that SSL in disabled and authentification is set only to Anonymous
4. Open Windows powershell modules
5. run Remove-PowershellVirtualDirectory command
6. run New-PowershellVirtuallirectory command
7. IISreset
I did not have to do the entire thing in my case. I did, however, check each and every e2010 (all 14) in the environment. NONE of them had the WinRM installed. All of them had the PowerShell vDir with anonymous disabled, but not requiring SSL.
What’s up with that? I checked the e2010 on server 2008 R2 prerequisites and the IIS WinRM is not listed for any role – which explains why it was not present on any of my servers.
So, my final resolution was:
YMMV
I have been having Lync connection issues – as in server drops, random disconnects, bad bad bad. I have done some local troubleshooting, and it appears that I have identified an issue that is very close to the “sun in the IR sensor” that used to shut down/disable HP printers.
It would appear that every time the microwave oven upstairs is running, the entire network drops. Not just the wireless, but the entire thing. This is interesting in that the kitchen is on the far side of the house – at least 80 feet way in a straight line, and upstairs to boot. I am hardwired in to Comcrappy home internet. Wireless is DLink. One difference between this setup and my previous residence is that the microwave is in a cabinet which may be focusing the oven radiation spill at this end of the house.
I don’t have one, yet.
YMMV
Get the guide here.
Tom Pacyk over at ConfusedAmused has a very nice set of scripts to help the Lync/OCS administrator look at the peak call numbers on your Mediation servers.
http://www.confusedamused.com/notebook/monitoring-ocs-and-lync-peak-call-capacity/
YMMV
In what is sure to be a long standing record (of sorts) for me (and maybe only me) – I just submitted a CSR to a public provider with 53 domains in the SAN field. This raised the question: “how many entries or names can be in that one field?” I know there has to be some sort of limit.
Handy Dandy, we had a TMG guy in the room, so we asked him. While he did not know off the top of his head, he did have an answer in mere minutes (where I had googled for about 10 and found squat).
http://social.technet.microsoft.com/wiki/contents/articles/3306.aspx
So, now we know the field is defined by a database, that a Windows PKI CA is limited to 4k of names, and that somewhere around 150 25 character domain names eat up just under 4k. By extension, we can assume (and we know what that means) that the Public cert providers are following the same RFC and that they will have a similar limit.
How about that? An answer to a question you did not know you had!
YMMV
A co-worker of mine put up this blog entry today, I like it. I too have closed the PowerShell window before I really wanted to. I use the F7 key, and the up/down arrows, but there is nothing like a literal log, especially when it comes to working up specific elements of a complex (or even brute force) script. My thanks to Mr. Jaworski to putting this together – his technique works on every PS install I have tried it on (so far 
I modified the instructions Scott lays out, because I don’t like having an unlimited growth file. I also did not see the point, however well taken, to some of the preliminary setup. So, I distilled down to one line:
start-transcript "c:\PS log $(get-date -f "yyyy-MM-dd HHmm").txt”
This simple one liner gets you this:
The resulting file looks like this:
Note that the date/time format is in something *I* like, so you might want to change that around a tad. But all the nice details are there.
Of course, you will need to “stop-transcript” when you get done.
YMMV
Things like built-in help files tend to get overlooked. We often work around things; and I like to have a separate reference handy. In the case of Lync, there is a mass of great information inside of the PowerShell command “get-help.” However, the amount of data can be daunting. For my own purposes, I extracted this data and massaged it a bit. There are 546 cmdlets – the Table of Contents runs 18 pages. The word doc has a clickable contents section, and each cmdlet has a hyperlink to the online content from TechNet.
You can get the document here.
Here is a PDF also for us iPad users.
Uh oh. that blog article cannot be found no more! Try this location instead:
https://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx
CU3 is out. Not listed on the update resource center quite yet, but here they are:
Lync 2010 Hotfix KB 2571543 (64 bit)
Lync 2010 Hotfix KB 2571543 (32 bit)
Lync Server 2010 Hotfix KB 2493736
Lync 2010 Group Chat Hotfix KB 2500446
YMMV
Onsite with a client and we are having issues with getting Exchange 2010 to enumerate CAS websites.
Here is the lovely error we got:
-------------------------------------------------------
An IIS directory entry couldn't be created. The error message is The remote procedure call failed and did not execute. . HResult = -2147023169 + CategoryInfo:NotInstalled: (servername\Rpc (Default Web Site):ADObjectId) [Get-OutlookAnywhere],
-------------------------------------------------------
Oh lovely. Cannot enable, disable, or get anywhere with this. Poked, prodded, googled, etc. Nada. Finally, in disgust, I believe what I am being told, to whit:
Action 'Disable Outlook Anywhere' could not be performed on object 'servername.'
Servername
Error:
The Outlook Anywhere feature has multiple configurations on servername.domain.com.
OK, so where does powershell get this data from? AD. So off we go to AD. And what did I find hiding out:
CN=Rpc (Default WebSite),CN=HTTP,CN=Protocols,CN=servername, CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=ExchangeOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
??
Two, count ‘em TWO RPC definitions. Yup, the server (and AD) thought there were multiple configurations. I carefully deleted one, and restarted the server. And now I get much better response in enumerating Exchange web sites/services. And OA can be configured again.
How it got there I have zero idea. Three other CAS servers in the Org are just fine. This one was just fine until about 1750 on 28 June 2011 when it was modified (according to AD) both at the same time. Some sort of hitch in the get-along as far as I can tell.
YMMV.
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26800
The above link shows step-by-step configuration tasks to set up the Direct SIP connectivity between Cisco Unified Communications Manager (CUCM) and Lync Server 2010. These steps include configuration of the media bypass feature that optimizes media flow by allowing Lync endpoints to directly establish a media connection with a gateway or private branch exchange (PBX) without going through the Lync Server Mediation Server.
Onsite with a customer setting up the initial E2010 DAG MBX servers. In constructing the MAPInet and REPLnet NICs on each server, we noticed that the static routes were not behaving as expected.
We checked the commands for establishing the static routes and how the NICs were setup. We were consistent across the board, on both subnets and sites. As an example, here is what we were using from the one site:
route add 10.12.93.0 mask 255.255.255.0 10.1.26.1 if 15 –p
This resulted in a 80% failure rate at that one site to establish a static route for the REPLnet traffic (for you score keepers, this equates to 40% failure across the environment). Obviously, we cannot continue with DAG construction until this is resolved.
netsh int ipv4 add route 10.12.93.0/24 “replnet” 10.1.26.1
Using the netsh method resulted in 100% success at not only putting a persistent route into place but actually having it work!
Thanks to http://fixmyitsystem.com/2010/10/adding-static-route-using-netsh-and.html for having a nice little article on this subject.
YMMV.
Having just ran around the world on this, it would appear that even with TMG SP1, Server 2008R2 does not allow TMG to do simple PPTP VPN. I foolishly thought I would insert the VPN service into my lab as a quick test. All my web publishing rules continued to work flawlessly; Lync Web Components; NAT for my Lync, Exchange 2010 publishing – everything worked except VPN.
If you are intensely interested, the VPN connection would be made, but no traffic was allowed to flow. Don’t know why, and at this point I don’t much care.
I fixed it by building a new server on 2008 SP2. If you are doing a project that includes TMG and want to have the same TMG provide VPN, you should most likely think about it and lab it before you continue.
Hopefully, someone can point out the errors of my ways and show me what I did wrong. YMMV.
Ever since somebody at Microsoft decided we needed the services.msc applet to open in “extended” mode, I have been clicking on “standard” to get the view I wanted. This last week I finally got fed up with this, and decided to do something about it. As it turns out, this is not the easiest thing to change. Apparently, us poor users are not allowed to change the behavior for the named services.msc. We are not worthy.
What you have to do is author a new named instance – and of course remember to use that one. I was unsuccessful at renaming, deleting, or otherwise removing the original services.msc. I am sure there is some method to do so, but I was unwilling to dink too much with an operating system that was working before I messed with it. YMMV.
Here is what I did: (the example is using an x64 Win7 O/S, but it works equally well for Server 2008, and I imagine, Vista (why are you using that?).
Go to c:\windows\system32 and locate the services.msc applet. Right-click it and select “author.”
When services opens, click File | Options as shown.
Now, change that console mode to “author.”
Say OK to this…
Change the view to standard…
Now, save this to a name and location of your choosing…
Now when you go to a command line (or in my case about 90% of the time a powershell prompt), and type in jmwservices.msc, I get this “new and de-proved” services applet in standard mode. I suppose you could mod the original references to the new applet if you want to get fancy.
Enjoy!
