Recommanderiez-vous le moyen meilleur et facile de transférer (ou copier) les abonnements d'un service de reporting à un autre service de rapport sur différents serveurs?
3 Réponses :
Combien d'abonnements y a-t-il?
Si theres une autre chose la plus simple serait de les recréer manuellement sur l'autre serveur.
Si nous parlons d'un montant équitable, il y a un service de rapport de base de données pour stocker les données d'abonnement, je crois appelé dbo.subscriptions. Je recommanderais d'abord à voir si vous pouvez voir les abonnements.
Sinon, si vous souhaitez transférer la base de données de serveur de reporting (planifications incluses), le lien suivant peut être utile:
MSDN Déplacement des bases de données du serveur de rapports sur un autre ordinateur
Salut .. J'ai vérifié la table d'abonnement et contient 45 lignes .. Je ne peux pas déplacer tout le service de rapport sur un autre serveur, car il écrasera les rapports d'extinction du serveur cible. Puis-je simplement obtenir la table d'abonnement et réinsérer des lignes sur le serveur cible?
Oui, vous devriez être assez facile à faire, mais incertain si cela serait verrouillé de modification, car il s'agit d'une base de données système, vérifiez votre rôle de premier ordre. Copier et coller serait une bonne solution simple autrement et vous devrez faire une importation / exportation des données: clic droit sur la DB> Tâches> Importation / Exportation et l'assistant vous guidera cependant, Heres un bon lien:
Salut a fait cela. Savez-vous pourquoi cela ne se présente pas?
Désolé .. corrigé cela .. La table des utilisateurs de Signaler Server DB pointe toujours sur le compte Windows de Old Server (E.G. OldServer \ WindowsAccount -> Changé de Newserver \ WindowsAccount)
Voici quelque chose que nous avons utilisé pour copier des abonnements à partir d'une SSR de 2008 à un serveur SSRS 2012. Vous aurez besoin des sources de données pour être configurées correctement à l'avance.
Sachez que le nom de la colonne 'Paramètre' est incorrect dans la sélection, il devrait être "Paramètres". J'ai ajouté une réponse plus complète qui inclut les tables correspondantes.
Construire sur la réponse de @ S.Juarez, ce script corrige son bogue qui brise les paramètres (et empêche ainsi les abonnements de fonctionnement), ainsi que des transferts entre les calendriers associés et les enregistrements d'utilisateurs de planification. Il conserve les mêmes guidons à la source et à la cible.
Le point de départ de l'utilisation de ce script est après avoir déjà transféré les rapports (par exemple à l'aide de l'outil ReportSync ), et vous avez configuré manuellement la sécurité sur tous vos dossiers de rapport sur le serveur cible. Vous devez également décider de l'enregistrement de l'utilisateur sur le serveur cible pour associer des abonnements avec, pour les cas où le nom d'utilisateur existe sur le serveur source et non sur le serveur cible. (Cela peut arriver dans des situations où vous décidez de ne pas recréer les utilisateurs de la cible ou lorsque vous ne pouvez pas le faire, car cette personne n'est plus un compte valide sur le domaine - c'est-à-dire qu'ils ont quitté votre organisation).
Avant de commencer, je vous recommande d'exécuter ce petit script contre vos bases de données Source et Target ReportServer et enregistrer les résultats. En outre, prenez des sauvegardes complètes des bases de données dans son ensemble. Ces étapes vous permettent de rentabiliser à la fois de petits et gros changements. La première partie de ce prochain script transférera les abonnements, suivis des annexes, puis des enregistrements de liaison. entre les rapports, les abonnements et les horaires. Vous devez mettre le nom de vos serveurs cible et source, le nom de votre utilisateur par défaut (doit déjà exister dans la table des utilisateurs cible), puis exécuter ceci sur le serveur source. Pour tester si votre migration a fonctionné correctement, vous pouvez exécuter une déclaration comme celle-ci contre le serveur cible. Le GUID devrait être un abonnement à partir de la table des abonnements, idéalement pour quelque chose qui sera livré à votre boîte de réception. si cela fonctionne, vous devez recevoir un email dans ~ 20 secondes. Si elle échoue, j'ai constaté que le meilleur endroit pour rechercher des informations de dépannage était dans les fichiers journaux SSRS, décrit ici . < / p>
Je prévois de migrer des abonnements d'un serveur à un autre. Alors que les SSRS gère des horaires en créant des emplois, créeront simplement des enregistrements dans les tableaux de votre script Créer des horaires d'abonnement de travail? Dans votre cas, vous avez déclenché manuellement un calendrier en créant une entrée dans la table addevent .
Hmm - bonne question. Je ne travaille plus à l'endroit où j'ai fait la migration du rapport, je ne peux donc pas vérifier comment les horaires / emplois ont été triés désolé - il y a quelque temps. Je me souviens bien qu'il n'y ait pas de plaintes concernant les souscriptions après la migration, alors je présume que cela signifie que tout était d'accord (que ce soit, soit que, soit que ce soit ne remarque pas le manque de rapports arrivant ... que je pense serait peu probable que nous «Réussion de centaines d'abonnements - quelqu'un aurait parlé).
Notez que lorsque vous passez de SSRS dans SharePoint 2013 à PBIRS, vous devez utiliser «Collate Basey_Default» sur quelques jointures.
J'ai eu cela en fonctionnement avec quelques modifications et un script supplémentaire pour la migration des abonnements axés sur les données.