service de reporting de souscription de transfert

Question

Recommanderiez-vous le moyen le plus simple et le plus simple de transférer (ou de copier) les abonnements d'un service de reporting vers un autre service de reporting sur un serveur différent?

Answer 1

Combien y a-t-il d'abonnements?

S'il existe un nombre faible, le plus simple serait de les recréer manuellement sur l'autre serveur.

Si nous parlons d'un montant raisonnable, alors il y a un service de rapports de base de données pour stocker les données d'abonnement que je crois appelé dbo.Subscriptions. Je vous recommande de regarder d'abord là pour voir si vous pouvez voir les abonnements.

Sinon, si vous cherchez à transférer toute la base de données du serveur de rapports (horaires inclus), le lien suivant pourrait être utile:

MSDN Moving the Report Server Databases to Another Computer

Answer 2

Voici quelque chose que nous avons utilisé pour copier les abonnements d'un 2008 SSRS à un serveur SSRS 2012. Vous aurez besoin des sources de données à configurer correctement à l'avance.

INSERT INTO Mercury.ReportServer.dbo.Subscriptions(SubscriptionID, OwnerID, Report_OID, Locale, InactiveFlags, ExtensionSettings, ModifiedByID, ModifiedDate, Description, LastStatus, EventType, MatchData, LastRunTime, Parameters, DataSettings, DeliveryExtension, Version) 
SELECT 
    --Path, 
    SubscriptionID 
    ,(SELECT UserID FROM <Destination Linked Server>.ReportServer.dbo.Users WHERE UserName = '<User from DB>') OwnerID 
    ,(select ItemId from <Destination Linked Server>.ReportServer.dbo.Catalog mCatalog where mCatalog.Path = Catalog.Path)Report_OID 
    ,Locale, InactiveFlags, ExtensionSettings 
    ,(SELECT UserID FROM <Destination Linked Server>.ReportServer.dbo.Users WHERE UserName = 'User from DB') ModifiedByID 
    , GETDATE() 
    ,Sub.Description, LastStatus, EventType, MatchData, LastRunTime, Parameter, DataSettings, DeliveryExtension, Version 

FROM ReportServer..Subscriptions Sub 
    LEFT JOIN ReportServer.dbo.Catalog ON Catalog.ItemId = Sub.Report_OID 
WHERE Path NOT IN 
    (
    SELECT Path 
    FROM <Destination Linked Server>.ReportServer.dbo.Subscriptions 
     LEFT JOIN <Destination Linked Server>.ReportServer.dbo.Catalog ON Catalog.ItemId = Subscriptions.Report_OID 
) 
--AND 
-- PATH LIKE '...' 

Answer 3

Miser sur la réponse de @ S.Juarez, ce script corrige son bug qui casse les paramètres (et empêche ainsi les souscriptions de travail), ainsi que les transferts à travers les annexes connexes et les dossiers Calendrier de l'utilisateur. Il conserve les mêmes GUID sur la source et la cible. Le point de départ pour utiliser ce script est après avoir déjà transféré les rapports (par exemple, en utilisant 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 quel enregistrement utilisateur sur le serveur cible auquel associer les abonnements, dans les cas où le nom d'utilisateur existe sur le serveur source et non sur le serveur cible. (Cela peut se produire dans des situations où vous décidez de ne pas recréer les utilisateurs sur 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'elle a quitté votre organisation). Avant de commencer, je recommande d'exécuter ce petit script sur vos bases de données ReportServer source et cible et d'enregistrer les résultats. En outre, effectuez des sauvegardes complètes des bases de données dans leur intégralité. Ces étapes vous permettent de revenir en arrière sur les petites et grandes modifications.

SELECT u.UserName, c.Path, Parameters, s.ExtensionSettings, s.Report_OID, SubscriptionID, u.UserID 
FROM dbo.[Subscriptions] s 
JOIN users u 
on s.OwnerID = u.UserID 
JOIN catalog c 
on c.ItemID = s.Report_OID 

La première partie de ce script suivant transférera les abonnements, suivi par les annexes puis les enregistrements de liaison entre les rapports, les souscriptions et les annexes. Vous devez entrer le nom de vos serveurs cible et source, le nom de votre utilisateur par défaut (doit déjà exister dans la table Utilisateurs cible), puis l'exécuter sur le serveur source. Pour tester si votre migration a fonctionné correctement, vous pouvez exécuter une instruction comme celle-ci sur le serveur cible. Le GUID doit être un SubscriptionID dans la table Subscriptions, idéalement pour quelque chose qui sera livré dans votre boîte de réception.

exec [ReportServer].dbo.AddEvent @EventType='TimedSubscription', @EventData='cb38a708-7735-4b5a-8ff3-e03ee1b18edb' 

Si cela fonctionne, vous devriez recevoir un courriel dans ~ 20 secondes. Si cela échoue, j'ai trouvé que le meilleur endroit pour rechercher des informations de dépannage était dans les fichiers journaux SSRS, described here.