samedi 20 avril 2013

Mise à jour Lync Phone Edition


 Product
 Version
Download
KB
Lync Phone Edition for Aastra 6721ip and Aastra 6725ip
4.0.7577
4387
Lync Phone Edition for HP 4110 and HP 4120
4.0.7577
4387
Lync Phone Edition for Polycom CX500, Polycom CX600 and Polycom CX3000
4.0.7577
4387
Lync Phone Edition for Polycom CX700 and LG-Nortel IP Phone 8540
4.0.7577
4387

Import-CsDeviceUpdate -Identity "service:webserver:rmi-lync.rmidom.intra" -FileName c:\temp\ucupdates.cab

Source : http://unifiedit.wordpress.com/2013/04/19/lync-phone-edition-mise-a-jour-avril-2013/

mardi 24 avril 2012

Erreur installation SCOM2012

Info: :Info:GetLocalizedAdminGroupName: Administrators Group Name is: BUILTIN\Administrateurs[11:13:09]: Error: :PopulateUserRoles: failed : Threw Exception.Type: System.UnauthorizedAccessException, Exception Error Code: 0x80070005, Exception.Message: Accès refusé. (Exception de HRESULT : 0x80070005 (E_ACCESSDENIED))[11:13:09]: Error: :StackTrace: à Microsoft.Mom.Sdk.UserRoleSetup.SetupProgram.populateUserRoles(String adminRoleGroup, String sdkAccount, InstallTypes installType, String installDirectory, Boolean overwriteExistingUsers) à Microsoft.EnterpriseManagement.OperationsManager.Setup.ServerConfiguration.PopulateUserRoles(String adminRoleGroup, String sdkAccount, String installDirPath)[11:13:09]: Error: :FATAL ACTION: PopulateUserRoles[11:13:09]: Error: :FATAL ACTION: DatabaseActions[11:13:09]: Error: :ProcessInstalls: Running the PostProcessDelegate returned false.[11:13:09]: Always: :SetErrorType: Setting VitalFailure. currentInstallItem: Database Configuration[11:13:09]: Error: :ProcessInstalls: Running the PostProcessDelegate for OMDATABASE failed.... This is a fatal item. Setting rollback.[11:13:09]: Info: :SetProgressScreen: FinishMinorStep.

http://social.technet.microsoft.com/Forums/en-US/operationsmanagerdeployment/thread/e5936efa-5f25-4d0f-9187-67469ac5ea90

I faces the same issue but when i add installation account into SQL server local administrator and grant it sql instance sysadmin role, the problem is solved.

Il faut donner les droits sysadmin au groupe BUILTIN\Administrateurs

Liste des éléments Web

Utilisez la commande :


netsh http show urlacl

mercredi 11 avril 2012

“All People” view in SharePoint 2010


One thing we have seemed to have lost is the “All People” link when managing users and groups from SharePoint 2007 in 2010, as shown below from a 2007 site
However, in SharePoint 2010, this link does not exist… Have no fear however. If you have copy & paste skills, you can get back there. It still exists. Just copy the URL from your 2007 site
http://my2007site.grace-hunt.com/_layouts/people.aspx?MembershipGroupId=0&FilterField1=ContentType&FilterValue1=Person
And drop the protocol, port, and host sections of the URL out, and use that with the protocol, host, and port of your 2010 site, and you are good to go.
http://my2010site.grace-hunt.com/_layouts/people.aspx?MembershipGroupId=0&FilterField1=ContentType&FilterValue1=Person
Simple and easy way to get back to that view. Then just add this as a favorite, or, even better yet, create aCustomAction to add it into the toolbar, or site settings page in 2010.

jeudi 8 mars 2012

Masques réseaux


Masque                           /x                       Nbr d'adresses
255.255.255.255 / 32 1
255.255.255.254 / 31 2
255.255.255.252 / 30 4
255.255.255.248 / 29 8
255.255.255.240 / 28 16
255.255.255.224 / 27 32
255.255.255.192 / 26 64
255.255.255.128 / 25 128
255.255.255.0 / 24 256
255.255.254.0 / 23 512
255.255.252.0 / 22 1 024
255.255.248.0 / 21 2 048
255.255.240.0 / 20 4 096
255.255.224.0 / 19 8 192
255.255.192.0 / 18 16 384
255.255.128.0 / 17 32 768
255.255.0.0 / 16 65 536
255.254.0.0 / 15 131 072
255.252.0.0 / 14 262 144
255.248.0.0 / 13 524 288
255.240.0.0 / 12 1 048 576
255.224.0.0 / 11 2 097 152
255.192.0.0 / 10 4 194 304
255.128.0.0 / 09 8 388 608
255.0.0.0 / 08 16 777 216
254.0.0.0 / 07 33 554 432
252.0.0.0 / 06 67 108 864
248.0.0.0 / 05 134 217 728
240.0.0.0 / 04 268 435 456
224.0.0.0 / 03 536 870 912
192.0.0.0 / 02 1 073 741 824
128.0.0.0 / 01 2 147 483 648
0.0.0.0

mercredi 7 mars 2012

Lync Update Mars 2012


he update for Lync CU5 is here, and there are some nice fixes in this latest batch.

Gateway pre-requisites

Regardless of your PSTN gateway type (basic, enhanced, etc), make sure you check with the vendor or your support provider to ensure there are no pre-requisites there before you upgrade Lync to CU5. It’s fairly common-place to need to upgrade the gateway to a current/certified version before taking any of the Lync components to a new CU level.
NET has advised that the UX needs to be running 2.0.2 (2.0v130) or above for CU5 support, and the VX needs to be at least 4.7.5v61.
If/as I come across any others I’ll let you know.

Don’t forget the Database Update!

As with the last 2 updates, there’s an accompanying update to the database. I found the instructions that accompanied the KB article to be a little misleading, so opted for the following, which is simply based upon the requirements from the CU4 documentation:
Standard Edition FE:
Install-CsDatabase –Update -LocalDatabases
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

Useful additions and fixes

I’ve scanned the respective KBs and thought the below were noteworthy:
2666344 You cannot add a DFS file share as a file store in Topology Builder of Lync Server 2010.
Nice to see that finally addressed!
2666326 You cannot share an application or the desktop in Lync Web App.
Could come in handy!
2664650 Microsoft push notification messages are not delivered to Lync mobile clients.
Goodie! A mobility fix.
2672944 A contact is displayed with an incorrect picture and incorrect presence information in Lync 2010.
I had a laugh – I’ve not seen this problem with Lync – but DEFINITELY with Facebook!!
2666709 An update is available for RCC enabled users to make video calls or conference calls in Lync 2010.
This one’s been long anticipated. Now, even if you’re using RCC, you can do video – but your audio now also comes from Lync, not your RCC’d phone. So if you want to use video, you also need a USB headset on your PC for the audio to accompany the call.
2637105 “Please verify your logon credentials and try again” error message when a user signs in to Lync Server 2010
2681509 Users have to manually input the user name every time that they sign in to the Lync 2010 client
I thought these were just nice-to-haves for IT support. One’s a fix, the other’s a more useful dialog box explaining an error.
2672935 Federated users do not receive a meeting invitation in Lync Server 2010
Yes, that could be embarrassing.
2673305 Packet loss occurs when you connect a telephone that is running Lync 2010 Phone Edition to a computer
Ooh. Yes, that sounds nasty. (The notes indicate it’s related to receiving multicast streams whilst tethered by USB, so perhaps not as bad as the title might suggest).
2666706 Description of a new feature that lets users set or change their presence information by using a telephone in Lync 2010 Phone Edition
This one’s a bit of a yawn-maker – but it’s bringing the Aries phones into feature alignment with the CX700/Tanjay, which has let you do this since day dot. So a nice-to-have if you have a mixture of phone models, as lots of our sites upgraded from OCS do.

Exchange?

In case you’re curious, I ran the ServerUpdateInstaller.EXE across my Exchange 2010 SP2 “Rollup 0” and it found nothing to update. But then it occurred to me – it uses various OCS plugins for IM through OWA… But that’s foranother post.

Some More Links

Here are the other items you might want to download. These remain unchanged in CU5:

mardi 28 février 2012

Lync Claims EWS Not Deployed






In the last few Lync deployments I’ve done I’ve run into two different instances where the Lync client was failing to login to Exchange Web Services to retrieve the conversation history and user voicemail. In both cases there wasn’t actually the red exclamation mark on those two tabs in the UI like you’d expect if there were an error; the client just hummed along like nothing was wrong. In each scenario if I viewed the configuration information you would see the client report “EWS Not Deployed”, which was odd because Exchange 2010 was most definitely deployed at both customer sites.


Sidenote: The EWS polling takes roughly 30 seconds to reach this state. If you view the configuration info immediately you’ll see “EWS OK”, which is only because Lync has tried yet. So be careful when testing this and thinking everything is just fine.
Solution 1: Verify the InternalURL and ExternalURL for the Web Services virtual directory are entered
The first fix was incredibly easy and after some more digging we determined this was only occurring when a client was external and logging in through an Edge server. When we looked at the Exchange Client Access Server we found this customer had not actually entered an ExternalURL parameter for the Web Services virtual directory. This works just fine for Outlook clients, but Lync is expecting this value to be filled out. If it’s not entered it assumes EWS is not deployed externally and doesn’t attempt a connection, which is a pretty reasonable action. You might argue the Outlook action is incorrect and it should treat it the same way. But anyway, the fix is to just fill out the ExternalURL and Lync will begin using that value to login to EWS successfully.
Sidenote 2: The information discovered by Lync via Autodiscover is cached in the registry at HKCU\Software\Microsoft\Communicator\<SIP URI>\Autodiscovery (Can you tell a Lync dev wrote the regkey name? Autodiscovery instead of Autodiscover?) You’ll see entries for the internal and external URLs for the Availability Service, Exchange Control Panel, Exchange Web Services, and Out of Office Assistant. I’ve been able to delete this entire registry key for quick testing and found it recreated with no issues.
Solution 2: Place https://<Your SMTP domain>/ in the Local Intranet Zone
The second instance of this issue was a little more complicated, and still doesn’t make much sense to me, but I figured I would share. In this case the customer did not have Outlook Anywhere published so we expected it to fail externally, but this error was actually occurring internally. After verifying the InternalURL was filled out correctly we started doing some traces and noticed the Lync client would make a GET request to the /Autodiscover/Autodiscover.xml file on Exchange, Exchange would return a 401 Unauthorized challenging for credentials like we expected, and then the trace died. There were be no more responses from the Lync client IP address sent to Exchange in the logs. We verified this on multiple machines and operating systems and concluded that the Lync client would never respond to the credential request! For what it’s worth, Autodiscover was working fine for Outlook clients and no special configuration had been done to Exchange.
So we put a call into PSS and they told me Lync will not read the SCP for Autodiscover in AD, even if the Lync client is internal and that it will do its own Autodiscover lookup (Can anyone confirm/deny this?). Therefore, it will fall back to https://domain.com/Autodiscover/Autodiscover.xml, and if that fails it should move on to https://autodiscover.domain.com/Autodiscover/Autodiscover.xml like an Outlook client. This is where it got weird – PSS told me from the ETL trace Lync was not falling back to the 2nd option, yet I could clearly see it make a request to IIS and not respond. From what they saw the Lync client was getting stuck on the 1st option which didn’t really exist. In any event, they had me add http://<domain.com>/ to the Local Intranet Zone on the client. Even though we knew this was not the location of Autodiscover and I really didn’t think it would make a difference it did solve the problem. After adding entry this we saw clients then try to resolve autodiscover.domain.com and grab the Autodiscover.xml file correctly from https://autodiscover.domain.com/Autodiscover/Autodiscover.xml. At this point the EWS status in the configuration information returned to EWS OK.
Sidenote 3: There is a thread on the Technet forums about this issue which suggests editing your applicationhost.config file on the Exchange server. I have to recommend against this and as you can see in the comments it hasn’t really fixed the problem for anyone. The solution is more likely one of the ones presented here.
source