Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Lors de la customisation de la MasterPage d'un SharePoint Foundation 2013, je suis tombé sur un os. Pour ne plus avoir de marges autour des pages de WebParts, et donc avoir un rendu proche de celui des wiki, j'ai codé le style suivant :

.ms-webpartPage-root { border-spacing:0 } 

Prévoyant d'autres modifications, j'ai mis le tout dans une librairie :

/Style Library/Style.css

Je voulais ajouter cette CSS à la fin du head. Sans raison apparente, mon code n'était pas pris en compte. Après plusieurs manipulations infructueuses, car non prise en charge par Sharepoint Foundation (ex :$SPurl qui a aussi besoin que l'on manipule les expressionBuilders) je suis arrivé à la solution simple et sans fioriture:

 < SharePoint:CSSRegistration name="/Style Library/Style.css" runat="server" / > 

Note : l'espace de "Style Library" est important pour que la feuille soit retrouvée.

De base, Visual Studio est malheureusement très pauvre en templates pour Workflow Foundation 4 :

  • 3 templates d'activités
  • 1 template de design.

Il y a quelques années, j'avais poussé 6 templates supplémentaires sur Skydrive dont 4 étaient aussi présents sur la galerie de Visual Studio.

Au vu du petit succès de ceux-ci, j'ai enfin pris mon courage à deux mains pour porter ces templates vers Visual Studio 2012 et 2013. Ces nouveaux templates, comme les précédents respectent les bonnes pratiques de WF4 et WF4.5. Ils comprennent donc l'écriture des metadatas.

Vous pouvez donc dès à présent en profiter via la boite à outils de gestion de vos extensions :

 

Ou si vous voulez télécharger le fichier VSIX : http://visualstudiogallery.msdn.microsoft.com/073c2a47-f666-4c84-8c7f-05b5ace26981

 

Une fois déployée, vous aurez le set de templates suivant :

 

Si tout se passe bien, je devrais publier sous peu, une extension avec des nouvelles commandes pour le designer de Workflow…

wait and see..

Pour qu'une activité expose des propriétés, deux choix s'offrent à nous :

  • Property : Une propriété CLR classique.
  • Argument : Une activité sur laquelle on définit une direction IN, OUT ou IN/OUT.

La raison pour laquelle on doit prendre l'une ou l'autre n'étant pas évidente, voici un petit récapitulatif des situations qui vous feront choisir l'une ou l'autre :

 

1. L'information est fixée lors sur design, elle ne change pas lors de l'exécution

Il faut utiliser alors une property. L'argument devant être exécuté pour fournir sa valeur, vous évitez ainsi d'utiliser inutilement trop des ressources.

 

2. L'information change lors de l'exécution

Si l'information fournie à votre activité doit être le fruit d'un travail préalable, il faut utiliser un InArgument<T> ou un InOutArgument<T>. Seuls les arguments peuvent contenir le fruit d'une Variable<T>. De la même manière, seuls les arguments peuvent interpréter une expression (Vb ou C#) lors de l'exécution.

 

3. L'information doit sortir de votre activité.

Seuls OutArgument<T> ou InOutArgument<T> peuvent sortir des valeurs de votre activité, pour que l'activité hôte de celle-ci puisse les récupérer dans une Variable<T>. On peut toujours envisager d'utiliser des ActivityFunc<T> ou ActivityAction<T>, mais ceci est vicieux et ne facilite pas la compréhension de votre activité par votre collègue (ou client) qui définit les workflows.

 

J'espère que ce petit récapitulatif vous sera utile ;)

Comment peut-on forcer une machine à changer d'état pour un état choisi?

Voilà une question qui m'est souvent posée. De base, ceci n'est pas possible « out of the box ». Certain disent qu'i il existe bien des « astuces » pour y arriver. Mais quand on y regarde bien, elles consistent presque toutes à réécrire sa propre usine à gaz pour héberger un Workflow totalement personnalisé pour l'hôte.

Pour être clair sur le sujet, pour forcer un état  il faut :

  1. Réécrire un état custom
  2. Réécrire une statemachine custom
  3. Réécrire un hôte dédié

Et à partir du moment où l'on a fait ce travail, dès que l'on voudra utiliser une fonctionnalité standard de WF, il faudra la réécrire…

Avez-vous vraiment besoin de coder votre propre Workfow Foudation, alors que Microsoft l'a déjà fait pour vous ?

Soyons claires, le titre ne reflète pas mon avis, ni même le contenu de cet article. Il ne sert qu’à attirer le chaland sur un contenu « coup de gueule ».

Depuis que je fais du .net, j’en vois et j’en entends des vertes et des pas mures sur .net et ses problèmes de performances. Dernièrement (hors contexte professionnel heureusement), j’ai été assez choqué par une situation qui ne se généralise peut-être pas encore, mais qui prend tout de même de l’ampleur : « n’utiliser que le constructeur par défaut d’une classe ».

Le framework fourmille de classes disposant de x constructeurs. Ceux-ci ne sont pas là juste pour faire beau dans le décor. Ils sont souvent destinés à une instanciation optimale.

Oui, dit comme cela, mes propos peuvent sembler étranges, et un peu old school ou totalement has been…

Cependant, quand je vois un modèle qui implémente INotifyProprtyChanged et que tout le monde utilise les accesseurs pour définir les propriétés de l’instance fraichement crée, ça me fou en rogne. Avec XAML, il ne faut donc pas s’étonner d’avoir des problèmes de performances.

Prenons une classe sans constructeurs (comme j’en vois trop) :

public class Item1 : NotifyPropertyChangedBase
{
    private Guid _id; 
    private Boolean _isRead;
    private Boolean _isStarred;

    public string Id
    {
        get { return _id; }
        set
        {
            if (_id == value) return;
            _id = value;
            RaisePropertyChanged();
        }
    }

    public Boolean IsRead
    {
        get { return _isRead; }
        set
        {
            if (_isRead == value) return;
            _isRead = value;
            RaisePropertyChanged();
        }
    }

    public Boolean IsStarred
    {
        get { return _isStarred; }
        set
        {
            if (_isStarred == value) return;
            _isStarred = value;
            RaisePropertyChanged();
        }
    }
}

Prenons une seconde classe similaire avec constructeurs :

public class Item2 : NotifyPropertyChangedBase
{
    private readonly Guid _id; 
    private Boolean _isRead;
    private Boolean _isStarred;

    public Item2() : this(Guid.NewGuid(), false, false) { }
    public Item2(Guid id) : this(id, false, false) { }

    public Item2(Guid id, bool isRead, bool isStarred)
    {
        _id = id;
        _isRead = isRead;
        _isStarred = isStarred;
    }

    public Guid Id
    {
        get { return _id; }
    }

    public Boolean IsRead
    {
        get { return _isRead; }
        set
        {
            if (_isRead == value) return;
            _isRead = value;
            RaisePropertyChanged();
        }
    }

    public Boolean IsStarred
    {
        get { return _isStarred; }
        set
        {
            if (_isStarred == value) return;
            _isStarred = value;
            RaisePropertyChanged();
        }
    }
}

L’instanciation de chacune avec les mêmes valeurs donnera ceci :

var i = new Item1{Id = id,IsRead = true, IsStarred=true};
var j = new Item2(id, true,true);

Rien de bien choquant. Si ce n’est qu’en instanciant la première classe, cela revient à écrire le code suivant :

public Item1(Guid id, bool isRead, bool isStarred)
{
    if (_id != id)
    {
        _id = id;
        RaisePropertyChanged();
    }
    if (_isRead != isRead) 
    {
        _isRead = isRead;
        RaisePropertyChanged();
    }
    if (isStarred != isStarred)
    {
        isStarred = isStarred;
        RaisePropertyChanged();
    }
}

Honnêtement, iriez-vous volontairement écrire ceci ?

Dans le cadre de projets d'intégration on-premise, j'ai eu à m'intéresser à SharePoint Foundation 2013. Bien qu'appréciant énormément le produit, je ne pas m'empêcher d'être déçus. Je résumerai les choses en 3 points :

 

1. Les manques

D'abord, il y a ces fonctionnalités de base qui me manquant cruellement :

  • Pas de Meta / taxonomie. Et donc aucune gestion centralisée des metadata d'entreprise L
  • La configuration initiale de la recherche est limitée. (Sorti de la configuration de base, rien n'est possible à partir du site de gestion, on doit passer par powershell… et encore, toutes les commandes ne sont pas disponibles… grrr !!!)
  • Pas de workflow manager, donc pas de workflow 2013 (Pourrat-on rester à vie avec des workflows 2010 ?).

     

2. Les nouveautés qui ne sont pas utilisables out of the box

Pour l'intégration on-premise, Sharepoint 2013 arrivant avec un lot de fonctionnalités nouvelles autour des « apps ». Dans un scénario entièrement on-premise on passe par des apps dites « provider-hosted ». Celles-ci ont besoin que la fonctionnalité de synchronisation des profils soit activée… fonctionnalité qui n'existe pas sur un Sharepoint Foundation.

Même avec une relation de confiance full trust entre la ferme SharePoint et les IIS des apps, on ne peut pas utiliser le template d'application de Visual Studio 2013. La solution consiste à ruser en utilisant les Claims avec une authentification Windows ou alors un provider partagé avec le SharePoint.

 

3. Conclusion

L'intégration d'apps dites « rovider-hosted » pouvant devenir un vrai cauchemar et Workflow 2013 n'étant pas pris en charge, les anciens modèles de développement / intégrations sont préférables, car plus simples. A mon sens, on commence à avoir un gros décalage en intégration sur Sharepoint Server et Sharepoint Foundation.

Bonne nouvelle pour les utilisateurs de Visual Studio 2013 et Oracle !

Les Oracle Developer Tools sont compatibles avec Visual Studio 2013. Comme souvent avec les produits oracle, la suppression de la version précédente est fortement conseillée si vous ne voulez pas avoir de problèmes.

Leur utilisation reste proche des versions précédentes (provider pour EF inclus). Quelques fonctionnalités sont mise à jour au passage.

Pour plus d'informations, ça se passe par ici

Bonne année et bon code pour cette année 2014.

Et tant qu'à faire, plein de beaux projets qui se réalisent ;)

Update : depuis le 20 décembre 2013, les ODT sont à jours et sont compatibles Visual Studio 2013

Pas de chance pour les utilisateurs des Oracle Developer Tools. Ceux-ci ne sont pas utilisables avec Visual Studio 2013 (et ceux même si on tente un enregistrement manuel, conformément à la documentation MSDN).

Après une tentative d'enregistrement manuelle, on peut juste constater dans les logs que les composants ODT ont des dépendances impossibles à résoudre, car liée à Visual Studio 2010 (ou 2012 en fonction de la version de l'ODAC testée).

ODT fonctionnant avec Visual Studio 2012, avec un peu de chance, la version 2013 ne devrait pas tarder.

Encore une fois, j’exhume un vieux code pour résoudre un problème courant… et surtout pour faire simple là où je vois des codes « qui font peur ».

Dans le cas présent, il s’agit de répondre à un message d’erreur qui arrive lorsque l’on veut modifier une Stream initialisée à partir d’un tableau de Bytes :

Memory stream is not expandable.

Ceci vient du fait que la Stream est marquée comme « non modifiable » lors de l’instanciation de la Stream. Certains préfèreront passer pas une Stream Custom, alors que la solution est simple :

Il suffit de passer par le constructeur par défaut puis d’ajouter le tableau de Bytes.

Le code :

// Code en erreur
Byte[] data= ... ;
MemoryStream stream = new MemoryStream(data, true);

Devient donc :

// Bon code
Byte[] data = ... ;
MemoryStream stream = new MemoryStream();
stream.Write(data, 0, data.Length);

Voila, simple et efficace Clignement d'œil

AllowBufferReceive est une option disponible dans les propriétés d'un service Workflow Foundation.

Elle a pour vocation de permettre la réception des messages dans le désordre, tout ne concevant les informations communiquées. Dans le monde structuré de WF, cela peut sembler totalement illogique.

En fait, cette option est à destination des services de type MSMQ. Pour un autre binding, on préférera utiliser une Parallel pour y glisser no Receive.

Donc pour résumé : évitez sauf si vous voulez empiler vos Receive pour avoir une visualisation verticale du worfklow.

Avec Workflow Foundation, le changement de nom d'un fichier XAML ou XAMLX n'entraine pas le renommage de l'activité ou du service.

Pour changer le nom, il suffit de :

  1. Ouvrir le Workflow à modifier.
  2. Clicker dans le designer de Workflow sans sélectionner une activité.
  3. Changer le nom dans la fenêtre propriété.

 

Pour une activité, on ne peut changer que le nom de l'activité.

 

Pour un service, on peut aussi changer la configuration WCF utilisée.

Sans contrat établi, un service de Workflow utilise un namespace par défaut « http://tempuri.org/ » et un nom de contrat « IService ».

Quand on utilise l'outil de test WCF, les messages on dont l'aspect suivant :

 

Pour fixer ces éléments, nous avons deux solutions :

  1. Changer la propriété ServiceContractName de chaque activité Receive

 

  1. Ouvrir le Workflow et utiliser la touche de raccourci F7 pour afficher le code XAML. Ensuite on peut remplacer les chaines indésirables via « rechercher /replacer ».

Petit désagrément qui vous a certainement touché si vous avez utilisé le SDK Open XML pour créer des documents Excel :

Le résultat des cellules calculées ne sont pas mis à jour automatiquement.

Ceci vient du fait que le format de fichier ne sert qu’à « porter » la donnée et le format. C’est Excel qui se charge de faire les calculs. Heureusement, le format *.xlsx dispose d’une propriété « ForceFullCalculation »  qui permet de forcer les calculs à l’ouverture d’un classeur.

Exemple d’utilisation :

// Ouverture d'un document
using (SpreadsheetDocument document = SpreadsheetDocument.Open(stream, true))
{
   // Forcer les calculs à l'ouverture
   document.WorkbookPart.Workbook.CalculationProperties.ForceFullCalculation = true;

   // Faire des modification sur le fichier

   // enregistrer le document
   document.WorkbookPart.Workbook.Save();
}

Avec un peu de retards, je souhaitais vous faire part de ma joie de recevoir un nouveau MVP Award. Merci à Microsoft pour cet honneur.

Un grand merci à tous les lecteurs de ce blog qui me sollicitent régulièrement par mail. Oui j'ai des articles en retard, et je vais remonter les manches pour les rédiger !

 

Aux MVP qui ont prévu d'aller au Summit : désolé de ne pas être parmi vous en novembre, ma compagne et moi-même attendons un heureux évènement qui doit se concrétiser à la même époque ;)

Comme disent les admins « Pour débloquer une configuration ratée, rien de mieux que PowerShell » (plus le temps passe, et plus je me fais à l'idée).

Encore faut-il que vous trouviez les commandes qui vont bien. Si comme moi vous n'êtes pas un pro du PowerShell, vous risquez de finir par abandonner au premier message vous disant que la commande n'est pas reconnue… Dommage?!

Il existe pourtant une solution simple : rechercher les modules installés sur votre serveur, et les importer.

 

Par exemple : dans le cadre d'un déploiement du cache partagé de l'AppFabric, je me suis retrouvé dans l'incapacité d'utiliser des commandes basiques telles que Remove-CacheHost ou Unregister-CacheHost. En fait, tout le module de configuration du cache était indisponible.

J'ai donc rendu une petite visite au répertoire Modules de PowerShell (ici en version 1.0 cela donne : %SystemRoot%\System32\WindowsPowerShell\v1.0\Modules\):

 

Ceci m'a permis d'en déduire qu'il me fallait utiliser la commande suivante pour charger le module manquant :

Import-module DistributedCacheConfiguration

Après import, il m'a donc est possible d'utiliser l'ensemble des commandes suivantes :

Le travail pouvait donc commencer ;)

Depuis quelques années, on parle de plus en plus de caches (AppFabric en tête). Malheureusement, une croyance urbaine veut qu'il soit impossible d'avoie le log, quand on active certain type de caches.

Par exemple :

Heureusement même dans ces deux cas, il est possible d'avoir des logs. Plusieurs options simples s'offrent à nous :

  • Coder un Behavior custom pour écrire ces propres logs.
  • Utiliser le MessageLogging.

Personnellement, je préfère le MessageLogging car il permet:

  • Une configuration souple et facilement adaptable.
  • Un branchement direct sur System.Diagnostics et donc un log identique à la Trace (encore faut-il l'utiliser)

Et vous, comment tracez-vous vos services ?

Encore une fois, j'exhume un petit peu de code pour répondre à un problème de POO qui semble simple, mais qui peut devenir cauchemardesque dès que l'on y associe WCF et les DataContract.

Le scénario est le suivant :

  • On a prévu d'utiliser une classe (Item) comme argument d'une méthode de service (Service1).
  • Côté client, l'objet réellement manipulé est une instance d'une classe qui hérite d'Item (ItemDerived).
  • Côté client, la classe de base n'est jamais manipulée directement.
  • Chaque classe ou interface est dans un namespace ou un assembly différent

Le diagramme de classe donne ceci

Pour appeler le service on utilise un code tel que celui-ci :

var result = proxy.Process(new ItemDerived());

 

Ou celui-là :

var result = proxy.Process((Item)new ItemDerived());

 

En l'état, les appels au service provoquent systématiquement une exception du style : le type utilisé lors de la sérialisation n'est pas du type attendu

Note : les messages d'exception semblent varier d'une version du Framework à l'autre.

 

Dans les faits, lors de la sérialisation, le DataContractSerializer est perdu :

  • Il attend une classe Item dans un namespace X avec un nom Y avec un DataContract (namespace X, name Y)
  • Il reçoit une classe ItemDerived dans un namespace U avec un nom V sans DataContract (on utilise juste l'héritage).

Il faut donc aider notre DataContractSerializer à s'en sortir. La solution est toute simple : partager une information claire et commune, le contrat.

La classe item est donc modifiée pour exposer deux constantes : le DataContractNamespace et le DataContractName.

Si on ne conserve que les déclarations de classes et des constantes, on obtient ceci :

    
      namespace Demos.Wcf.Base

    
  

    
      {

    
  

    
          // Use a data contract as illustrated in the sample below to add composite types to service operations.
						
    
  

    
          [DataContract(Name = DataContractName, Namespace = DataContractNamespace)]

    
  

    
          public class Item
										
    
  

    
          {

    
  

    
              protected const String DataContractName = "Item";

    
  

    
              protected const String DataContractNamespace = "Datas";

    
  

    
          }

    
  

    
      }

    
  

 

    
      namespace Demos.Wcf.Inherit

    
  

    
      {

    
  

    
          [DataContract(Name = DataContractName, Namespace = DataContractNamespace)]

    
  

    
          public class ItemDerived : Item
												
    
  

    
          {

    
  

    
          }

    
  

    
      }

    
  

 

Note : J'ai découvert par hasard que mes constantes protected pouvaient être utilisées via les attribues de la classe dérivée.

 

En partageant ces informations, on peut maintenant utiliser des classes dérivées avec notre proxy. Il n'y a plus d'exceptions.

Simple comme WCF ;)

 

   

 Heureux propriétaire d'une tablette sous Windows 8 (Asus Vivotab Smart), j'ai vu mes besoins en stockage augmenter (quelle idée folle m'est passée par la tête, quand j'ai installé Visual Studio….). J'ai donc ajouté une carte micro SD à ma tablette. Je dispose maintenant de deux espaces de stockage de 64Gb. Mon objectif étant d'utiliser ma carte SD pour stocker mes données, j'ai voulu déplacer le stockage de l'application SkyDrive (version bureau Windows).

   

 Et là, c'est le drame : Le bouton est grisé, car j'utilise mon compte Microsoft pour me m'identifier. Je ne peux donc pas supprimer le lien SkyDrive.

 

 

Pour pouvoir changer ce lien, et donc le dossier local, il faut désinstaller l'application. On doit donc ouvrir la liste de programmes et supprimer SkyDrive (vive le filtrage des listes via la recherche en haut à droite)

 

 

Vient alors, un nouveau problème : Skydrive n'accepte pour répertoire de stockage local, que des partitions NTFS sur un disque fixe.

Pas de soucis, on peut monter notre carte SD comme dossier NTFS. SkyDrive ne se rendra même pas compte qu'il s'agir d'une carte SD (bien entendu, il est conseillé de ne plus retirer la carte de la tablette).

Il faut donc lancer le gestionnaire de disque. Après récupération des éventuelles données déjà présentes sur la carte, on peut supprimer la ou les partitions déjà existantes. On peut alors créer une nouvelle partition :

 

L'assistant se lance alors.

 

Il faut ensuite choisir « Monter dans le dossier NTFS vide suivant » et cliquer sur « Parcourir »

 

Ceci permet d'ouvrir la fenêtre suivante. Dans mon cas, j'ai choisi de créer ce dossier à l'emplacement suivant « c:\CarteSD »

Après validation des deux boites de dialogue, arrive le choix du nom du volume. NTFS est grisé, ce qui est logique, car on utilise notre partition comme dossier NTFS.

Après formatage, on se retrouve alors avec un affichage des disques similaire à ceci

 

Ma carte est alors disponible via le dossier NTFS. Je peux donc y copier le contenu de mon ancien dossier SkyDrive (en pensant au passage à supprimer l'ancien dossier pour gagner de la place sur C:\)

 

À partir de cet instant, je peux procéder à l'installation de SkyDrive de manière classique, jusqu'au choix du dossier local.

 

Après validation du choix du dossier « c:\CarteSD », je dois confirmer l'utilisation de celui-ci, car il contient déjà mes anciennes données.

 

Une dernière petite vérification sur le chemin affiché par SkyDrive. Si c'est bon, on valide et le tour est joué.

 

Tada !!!

 

Note : Pour mon usage perso, j'ai aussi déplacé mes librairies et mon dossier TFS sur la carte…

 

Via ce billet, je me propose de partager avec vous mon ressenti sur le mode Core+Interface minimale de Windows 2012.

Note : ceci est un avis de Deve qui a besoin d'une infra de tests à la maison qui soit peu gourmande en temps de maintenance et dont le porte-monnaie n'est pas extensible. Ce n'est pas le retour d'un IT pro qui à sa salle blanche sur son lieu de travail.

Introduction

Depuis Windows 2008, Microsoft propose deux modes d'installation pour ses serveurs :

  • Un mode complet (interface windows classique)
  • Un mode core (interface réduite à la console, tout ou presque se fait en ligne de commande)

Les avantages du mode Core sont nombreux, mais n'étant pas IT, je ne vais pas m'appesantir sur la liste de ceux-ci. Je note principalement le fait qu'un serveur Core n'a besoin que de très peu de ressources pour fonctionner correctement (ex : mon contrôleur de domaine de test n'a que 512Mo de Ram).

Côté inconvénient,… dans mon cas, il n'y en a pas beaucoup. Ou plus exactement, avec 2012, il y en a beaucoup moins. Ils se situent principalement au niveau de la liste des produits supportés (ex : aujourd'hui le Framework .net n'est pas complet, les namespaces dédiés à l'interface Windows sont manquant, ce qui est normal). Il faut donc se renseigner avant de se lancer dans une installation.

Pour mon usage, le mode Core avait un gros point noir avant 2012 : sa console (merci de ne pas trop faire attention à mon humour à 2 centimes).

 

Windows 2012 en mode minimal interface

Avec Windows 2012, Microsoft offre une troisième possibilité :

  • Un mode interface minimale avec consoles.

Dans ce mode, on a la console type DOS et le minimum pour utiliser les MMC de Windows 2012. En plus, il est possible de passer d'un mode à l'autre sans réinstaller son serveur (un reboot est nécessaire après chaque changement de mode).

Voici une capture de ma console Server Manager : (comme on peut le voir, je n'ai activé que la feature Graphical management)

Pour revenir à un mode plus classique, il me suffit d'ajouter la feature Desktop Experience et de rebooter mon serveur.

 

Mon usage

Mon objectif étant de simuler un fonctionnement H24 d'une ferme SharePoint ou AppFabric, j'ai choisi de migrer mon serveur Hyper-V qui tournait sous 2008R2 (installation en mode complet). La migration a été faite à la sortie de Windows 20012 RTM avec une simple clé USB et en pilotant l'installation à partir d'un RDP (même pas peur). Après vérification que mon serveur fonctionnait bien sous 2012 (durant une petite semaine), j'ai retiré la feature Desktop Experience. Mon objectif étant d'utiliser le serveur à partir d'un bureau à distance, je n'ai effectué aucune customisation ni ouverture de droits pour utiliser les consoles.

Depuis bientôt un an, mon Hyper-V de test utilise donc un Windows 2012 en mode minimale interface. Pour ajouter/supprimer/configurer mes VM, j'utilise simplement le bureau à distance. Ce qui me permet d'utiliser mon serveur à partir de mon PC ou de ma tablette.

En pratique, mon bureau ressemble à ceci (par défaut, seule la console est ouverte):

 

Mon objectif étant de piloter mon Hyper-V, j'ai créé une MMC avec la Snap-In Hyper-V. Je dispose donc de tout ce qu'il faut pour travailler.

 

Les commandes à connaitre

Vu que l'on ne dispose pas de menu pour lancer ses applications, il faut connaitre quelques commandes :

sconfig (indispensable si on ne veut pas utiliser les mmc et rester en mode Core) :

 

servermanager pour avoir accès la console de gestion du serveur (uniquement possible en mode minimal interface)

 

mmc pour ouvrir une console vide. On peut y ajouter nos snap-in et enregistrer la mmc pour un usage ultérieur.

start cmd pour disposer d'un seconde console.

cd, mkdir.. etc… pour gérer les fichiers, naviguer sur vos volumes (penser à utiliser la touche Tab pour profiter de l'autocomplétion sur les noms de fichiers)

Le raccourci Ctrl+Alt+Fin pour faire un Ctrl+Alt+Supr via RDP (très pratique quand on ferme par erreur sa console, on peut alors ouvrir le gestionnaire de tâches pour lancer cmd).

taskmgr pour avoir accès au gestionnaire de tâches (on peut aussi lancer le moniteur de ressources complet à partir de l'onglet performances)

 

Alors heureux ?

Honnêtement, oui. Je suis très satisfait de mon installation. Je n'ai pas trouvé de réels inconvénients. Mon serveur fonctionne H24, mes VM sont opérationnelles et je peux observer leur fonctionnement en continu (j'ai même quelques VM en mode Core et minimal).

Je recommande fortement ce genre d'installation si vos moyens de virtualisation sont limités.

Pour les développeurs comme moi, j'ai trouvé une paire d'avantages non négligeables :

  • Les performances de mon serveur ne se sont pas dégradées alors que je ne fais rien pour la maintenance.
  • Les mises à jour sont réduites, donc on fait peu de maintenance et de reboots.


Les 10 derniers blogs postés

- Focus Sauvegardes SharePoint par Le blog de Patrick [MVP SharePoint] le il y a 3 heures et 5 minutes

- Technofolies, votre évènement numérique de l'année par Le Blog (Vert) d'Arnaud JUND le 09-26-2014, 18:40

- Xamarin : From Zero to Hero par Fathi Bellahcene le 09-24-2014, 17:35

- Conférences d’Automne 2014 par Le blog de Patrick [MVP SharePoint] le 09-24-2014, 14:53

- [TFS] Supprimer un projet de Visual Studio Online par Blog de Jérémy Jeanson le 09-22-2014, 20:42

- Nouveau blog en anglais / New blog in english ! par Le blog de Patrick [MVP SharePoint] le 09-18-2014, 18:42

- [ #Yammer ] From Mailbox to Yammer and back / De votre messagerie vers Yammer et retour ! par Le blog de Patrick [MVP SharePoint] le 09-15-2014, 11:31

- [ #Office 365 ] New service settings panel / Nouveau panneau de paramétrage des services par Le blog de Patrick [MVP SharePoint] le 09-11-2014, 08:50

- Problème de déploiement pour une démo SharePoint/TFS? par Blog de Jérémy Jeanson le 09-10-2014, 21:52

- [ #Office365 ] Delve first impressions / Premières impressions sur Delve par Le blog de Patrick [MVP SharePoint] le 09-09-2014, 16:57