Un problème de vignette/miniature dans vos liens partagés sur Facebook ?

Un problème de vignette/miniature dans vos liens partagés sur Facebook ?

J'ai fait une petite erreur de manipulation lors du partage de mon précédent billet sur Facebook. Rien de bien grave, juste un mauvais choix de vignette, mais le résultat du coup ne me plaisait pas trop. La correction n'étant pas possible, j'ai tout bonnement supprimé le lien de mon statut et tenté de renouveler l'opération de partage.

Damned, l'image que je veux sélectionner n'est en fait pas disponible ! Un coup d'oeil au billet sur le blog : normal me direz-vous, j'ai oublié de mettre l'image en question dans l'article d'origine... Une petite correction en local, une mise à jour de la version en ligne, un retour sur FB et... rien. La nouvelle image n'est pas proposée pour un passage en vignette. Damned ! (bis)

Partager un lien

Partager un lien c'est simple, on peut (entre autres) copier l'URL et la coller dans la zone dédiée à cet effet. Lier une des images de l'article pour en faire la miniature placée en tête ça l'est aussi. Une fois l'URL saisie Facebook se charge de parcourir la page et de vous proposer une miniature de toutes les images importantes qu'il trouve dessus.

Et c'est là qu'il y a un petit « truc » à savoir. Au moment où vous entrez l'URL à partager pour la première fois, Facebook va enregistrer une liste d'informations sur ce lien, et ne plus y touchez (probablement pendant un laps de temps déterminé et sur lequel je n'ai trouvé aucune information dans les FAQ).

Vous aurez beau enlever ou ajouter des méta-données, du contenu, des images, des vidéos, j'en passe et des meilleurs, il ne prendra pas la peine de revenir consulter la page au bout de votre lien.

Comment forcer une mise à jour ?

Heureusement, il existe un moyen de forcer FB à se rafraîchir la mémoire. La solution est cependant bien cachée : il faut en effet se rendre sur les outils de Facebook Developers, et pas sur le Facebook classique réservé aux utilisateurs.

D'ici, vous suivrez le lien « Ajouter Facebook à mon site », puis cliquerez sur « SDKs & Tools » dans le menu, puis sur « Tools » et enfin sur l'outil « URL Linter », le dernier lien bien caché tout en bas des propositions. Pour les impatients, le lien direct c'est par ici.

S'ouvrira alors la page de l'« analyseur d'URL » de Facebook. A partir de là les choses sont bien simples, il suffit de copier à nouveau l'adresse de votre page web et de cliquer sur « Lint ». FB va alors effacer toutes les données qu'il avait en mémoire sur votre page, et relancer son analyse de zéro.

Pas mal d'informations vous seront alors retournées, informations bien utiles notamment aux webmasters, mais elles ne vous concernent pas directement. Le but ici est juste d'effacer les vieux souvenirs erronés de FB et de le forcer à prendre un nouvel instantané.

Ceci fait, vous pourrez alors relancer le partage de votre lien, toutes les données seront bien à jour.

C'est tout.

Élémentaire mon cher Watson !

Need to change the root certificate validity period

You can change the validity period in the \Windows\CAPolicy.inf
file on the root CA and then renew the root CA certificate. The renewed
certificate will then have the desired validity period. You'll still have
to distribute this new certificate otherwise all of your affiliated
customers will still have a copy of the old certificate with the old
validity period.

If \Windows\CAPolicy.inf doesn't exist, you can create them with this format:

[certsrv_server]
RenewalValidityPeriodUnits=5
RenewalValidityPeriod=years

Fix for SCOM DNS 2008 External Resolution Monitor in Constant Error State

If you're using System Center Operations Manager 2007 (SCOM) you may notice that your Windows Server 2008 DNS servers are in a chronic critical state, due to the DNS 2008 External Resolution Monitor. This monitor is in the Windows Server DNS 2000/2003/2008 Management Pack for Operations Manager 2007.

The DNS 2008 External Resolution Monitor performs an NSLOOKUP query for a host (NS) record at www.microsoft.com to verify that external resolution is functioning properly. Further details can be read here.

Assuming that DNS forwarding and name resolution is functioning properly, you can correct this false error by creating an override for the Query Type. Override the default value (ns) for the DNS Server class with the override value of A, as shown below:

This will cause the monitor to perform lookups for A records, which should succeed. If the monitor still fails, you may indeed have a DNS name resolution problem.

Root Management Server Unavailable

Alert: Root Management Server Unavailable.

Source: SCOM01.DOMAIN.LOCAL

Path: SCOM01.DOMAIN.LOCAL

Last modified by: System

Last modified time: 9/2/2008 1:18:19 AM

Alert description: The root management server (Healthservice) has stopped heartbeating soon after 9/2/2008 1:17:18 AM. This adversely affects all availability calculation for the entire management group.

After the upgrade to SP1, our SCOM server started to give the above alert every minute or so. After much research and a call to Microsoft to confirm. This is in fact a bug, Microsoft's explaination is as follows "As the RMS gets busy with hundreds of client to monitor, the health service will be slow to response which causes it to skip heartbeats. This in turn trigger the alerts." This can get really annoying if someone is subscribed to email/IM notification. Here is the work around:

1. Regedt32
2. Locate HKEY_LOCAL_MACHINE -> SOFTWARE -> MICROSOFT -> MICROSOFT OPERATIONS MANANGER -> 3.0 -> SDK SERVICE
3. Right click - New Key
4. Enter "RHS Watcher"
5. Right click "RHS Watcher" -> New -> DWORD
6. Enter "MinutesToWaitBeforeAlerting"
7. Double-click on "MinutesToWaitBeforeAlerting" and enter value of 5
8. Close regdt32 and open Services.msc
9. Restart OpsMgr Config Service, OpsMgr Health Service, and OpsMgr Health Service

This should do the trick, basically what you just did is tell delaying the SDK Service from sending out alerts for 5 minutes, at which time it should have received the next heartbeat.

Which hotfixes should I apply?

Common OpsMgr 2007 Post-R2 hotfixes:

This list ABSOLUTELY assumes you are at OpsMgr R2-RTM level as a base (6.1.7221.0).

MP Update	Microsoft.SystemCenter.2007.mp 6.1.7695.0 Microsoft.SystemCenter.OperationsManager.2007.mp 6.1.7695.0 Microsoft.SystemCenter.OperationsManager.AM.DR.2007.mp 6.1.7695.0 Microsoft.SystemCenter.OperationsManager.Reports.2007.mp 6.1.7695.0 ODR.mp 6.1.7695.0	New reports, knowledge, monitors, rules. See MP Guide.	MP import only
2251525 R2 CU3	OpsMgr 2007 R2 CU3 Cumulative Update Multiple. See KB Article. Note this is a DLL update, MP updates, and SQL scripts update.	Many updates. See KB article for CU3, CU2, and CU1 for full list.	RMS MS GW Agents AuditCollector Console WebConsole MP Import TSQL Script
971233	none	The console shows customized subscriptions SMTP{GUID} after you upgrade to OpsMgr R2 from OpsMgr SP1	Operations Database (TSQL only)

Common OpsMgr 2007 Post-SP1 hotfixes:

This list ABSOLUTELY assumes you are at OpsMgr SP1 level as a base (6.0.6278.0). These DO NOT APPLY these to OpsMgr R2.

MP Update	Microsoft.SystemCenter.2007.mp 6.0.6709.0 Microsoft.SystemCenter. OperationsManager.2007.mp 6.0.6709.0 Microsoft.SystemCenter. OperationsManager.AM.DR.2007.mp 6.0.6709.0	Agent restarts, many other critical enhancements	Management Pack Import only (Import via console once extracted)
2028594	SP1 Cumulative Update 1. Multiple files. See KB article	Many. See KB article	RMS MS GW Agents Consoles MP Import SQL Scripts (OpsDB and DW)
971541	SP1 Rollup hotfix. Multiple files. See KB article	Many. See KB article	RMS MS GW Reporting Agents Console MP Import
972881	Managedentitychange.sp.sql	The changes to the display name of a managed entity are not synchronized in the Operations Manager Data Warehouse database	Data Warehouse Database (T-SQL only)
954643	Managementpackinstall.sp.sql	Event ID 31569 is logged after you install a management pack that includes reports on a System Center Operations Manager 2007 SP1 server	Data Warehouse Database (T-SQL only)
974254	Autotablecreation.sql Viewcreatesprocs.sql	1. Unable to create large number of groups. 2. Import fails when importing an MP or when creating a MP from a template	Operations Database (TSQL only)

WMI leaks memory on Server 2008 R2 monitored agents

Here is something that a customer brought to my attention, and is probably impacting you already.

They noticed that WMI on some of their Server 2008R2 monitored agents was consuming a large amount of memory – and continually increasing. I started tracking this in SCOM by writing a rule to collect the Process\Private Bytes of all WMI processes (WmiPrvSE*) to check.

Sure enough – a handful (but not all strangely) of my Windows 2008 R2 monitored servers are exhibiting this behavior. Below is a graph where see can see most processes are consuming ~20MB or less, but some are steadily increasing – consuming 400MB of RAM or more.

These are some signs that this might be impacting you in OpsMgr:

You might get some alerts in the console like the following:

Workflow Runtime: Failed to run a process or script

The process started at 1:22:12 AM failed to create System.Discovery.Data. Errors found in output:

C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 5\4235\AlertUpdateConnectorDiscovery.vbs(16, 1) SWbemObjectSet: No more threads can be created in the system.

Command executed: "C:\Windows\system32\cscript.exe" /nologo "AlertUpdateConnectorDiscovery.vbs" {A7504CAE-3EA5-5B1F-CDA4-A4593E4D85FD} {F8AEF188-D663-9719-3FD8-94B2AF6F0726} SQL2V1.opsmgr.net
Working Directory: C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 5\4235\

One or more workflows were affected by this.

Workflow name: AlertUpdateConnector.ConnectorDiscovery
Instance name: SQL2V1.opsmgr.net
Instance ID: {F8AEF188-D663-9719-3FD8-94B2AF6F0726}
Management group: PROD1

Or:

Workflow Runtime: Failed to run a WMI query

Object enumeration failed

Query: 'SELECT DisplayName, Name, StartMode FROM Win32_Service WHERE Name="ClusSvc" and StartMode!="Disabled"'
HRESULT: 0x80041006
Details: Out of memory

One or more workflows were affected by this.

Workflow name: Microsoft.Windows.Cluster.Service.Discovery
Instance name: SQL2CLN1.opsmgr.net
Instance ID: {90476733-8FA9-1718-152C-932FF9AB9BC6}
Management group: PROD1

Or:

Workflow Runtime: Failed to run a WMI query

Object enumeration failed

Query: 'SELECT NumberOfProcessors FROM Win32_ComputerSystem WHERE DomainRole >1'
HRESULT: 0x800705af
Details: The paging file is too small for this operation to complete.

One or more workflows were affected by this.

Workflow name: System.Mom.BackwardCompatibility.Computer.Server.DiscoveryRule
Instance name: SQLDB1.opsmgr.net
Instance ID: {AF7C2749-FF52-E354-EEAE-8CFCA3541607}
Management group: PROD1

The details of the script or discovery or workflow are irrelevant. What is relevant here is seeing the messages “No more threads can be created in the system” and “Out of memory” and “The paging file is too small for this operation to complete”.

Those are tell-tale signs of a memory leak or memory pressure, and in this case caused by WMI.

Sure enough – when I check this system, I can easily see there is an issue:

If you are running Server 2008R2 on ANY monitored system, it is highly likely that you need to apply this hotfix.

It turns out there is a hotfix for Windows 2008 R2 – which addresses a possible leak when an application queries the Win32_Service class frequently. A monitoring tool would do this – and therefore OpsMgr can accelerate this leak in the OS.

http://support.microsoft.com/kb/981314

Enable SQL 2005 broker service for SCOM 2007

SCOM 2007 uses SQL2005 broker service to perform discoveries, so before you use the Discovery Wizard to install agents, you need to set the Enable_Broker value.

To set ENABLE_BROKER

1. Open SQL Server Management Studio. 2. In the Connect to Server dialog box, select the appropriate values in the Server type list, in the Server name list, in the Authentication list, and then click Connect. 3. Click New Query. 4. In the query window, enter the following query: ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE 5. Click Execute. 6. Enter the following query: ALTER DATABASE OperationsManager SET ENABLE_BROKER 7. Click Execute. 8. Close SQL Server Management Studio. Note Closing SQL Server Management Studio closes the connection to the database in single user mode. Depending on your configuration, you may have to manually kill any process that is connected to the database before completing the ALTER query below. 9. Open SQL Server Management Studio. 10. In the Connect to Server dialog box, select the appropriate values in the Server type list, in the Server name list, in the Authentication list, and then click Connect. 11. Click New Query. 12. In the query window, enter the following query: ALTER DATABASE OperationsManager SET MULTI_USER 13. Click Execute.

You can verify the setting for ENABLE_BROKER is set to 1 by using this SQL query: SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'.

I was following the above instruction but when I try “ALTER DATABASE OperationsManager SET MULTI_USER”