1. Na serwerze z 64-bitowym SQL Serverem zainstalowałem 32-bitową wersję SQL Server Express.

2. Utworzyłem linked server pomiędzy bazą danych Accessa i SQL Server Expressem.

EXEC sp_addlinkedserver
@server = N'AccessDB',
@provider = N'Microsoft.Jet.OLEDB.4.0',
@srvproduct = N'OLE DB Provider for Jet',
@datasrc = N'C:\DB\accessdb.mdb'
GO

Wszystko o linked serverach można znaleźć w msdn Microsoftu.

3. Komunikacja pomiędzy 32 bitowym i 64 bitowym zapewniłem dzięki stworzeniu kolejnego linked servera.

EXEC sp_addlinkedserver @server=N'Express32', @srvproduct=N'', @provider=N'SQLNCLI', @datasrc= N'ServerName\SQLEXPRESS'; 

4. W expressie dla wygody stworzyłem widoki do interesujących mnie tabeli, m.in widok vTest. W 64bitowym SQL Server mogę już korzystać z danych z accessa!

SELECT * FROM Express32.Test.dbo.vTest

Cel:
Przeniesienie wielu folderów z biblioteki do zdefiniowanego innego.

Próby rozwiązania:

1. Zamapowanie sharepointowej biblioteki, jako dysku sieciowego i wykonanie operacji wytnij, wklej.
Tutaj pojawił się problem, połączenie z zamapowanym dyskiem trwało tak długo, że zawieszało Eksploratora Windows.
Zmiana ustawień połączenia lokalnego w Internet Explorer okazała się być rozwiązaniem problemu z wolnym połączeniem.
Wystarczyło odhaczyć ustawienie automatycznego wykrywania ustawień sieci.

1. Instalujemy pluginy grails: spring-security-core oraz spring-security-kerberos

$grails install-plugin spring-security-core
$grails install-plugin spring-security-kerberos 

2. Dodajemy użytkownika w Active Directory, który posłuży nam do zarejestrowania SPN (Service Principal Name) naszej aplikacji

 Setspn -a http/<computername>.<domainname> <domain-user-account>

uwagi: <computername>.<domainname> musi się dokładnie tak samo nazywać, jak host, gdzie później będzie uruchomiona aplikacja.

3. Generujemy na serwerze domenowym plik keyTab.

ktpass /out kerberos.keytab /mapuser <domain-user-account>@<DOMAIN.HOST.FULL.NAME> /princ HTTP/<computername>.<domainname>@<DOMAIN.HOST.FULL.NAME> /pass * 

4. Wygenerowany plik umieszczamy w miejscu dostępnym dla naszej aplikacji.

5. Dodajmy wpisy do pliku konfiguracyjnego Config.groovy.

grails.plugins.springsecurity.kerberos.ticketValidator.servicePrincipal = 'HTTP/<computername>.<domainname>@<DOMAIN.HOST.FULL.NAME>'
grails.plugins.springsecurity.kerberos.ticketValidator.keyTabLocation = 'file:///home/grails/kerberos.keytab'

6. W przeglądarce konfigurujemy zaufaną witrynę (tutaj firefox 4) :

url: about:config

network.negotiate-auth.trusted-uris: <computername>.<domainname>

ALTER TABLE Slowniki.RodzajUbezpieczenia ALTER COLUMN mnoznik DECIMAL(6,5)

Jednak dzięki temu, że w Akeeba Kickstart jest możliwość ustawienia by plik rozpakował się na zdalny adres FTP, więc z sukcesem z tego skorzystałem. CMS Joomla działa w home.pl bez problemu.

Natomiast z samym komponentem AkeebaBackup nie zanotowałem żadnych problemów – poza tym, że po przeniesieniu wizardem trzeba odświeżyć ścieżki, ale to tylko formalność.

Rozwiązanie:

# stsadm -o migrateuser -oldlogin  domena\starylogin -newlogin domena\nowylogin -ignoresidhistory

# iisreset

Działa!

PS.
Cały artykuł dotyczący migracji loginów tutaj.

SPUser uzytkownik.Groups

Jest to dobry tok myślenia tylko w przypadku, gdy użytkownicy przypisywani są do grupy SharePoint w postaci pojedynczych użytkowników Active Directory a nie Grup AD.

W tym drugim przypadku musimy użyć SPUserToken i SPGroup.ContainsCurrentUser.

Przykład:

SPSite site = new SPSite(“http://sharepoint:100/”);
SPWeb web = site.OpenWeb();

Label label = new Label();

this.Controls.Add(label);
SPUserToken userToken = site.UserToken;
using (SPSite contextSiteColl = new SPSite(“http://sharepoint:100/”, userToken))
{
using (SPWeb contextSite = contextSiteColl.OpenWeb())
{
label.Text += ” Site:” + contextSite.Name;
foreach (SPGroup grupa in contextSite.Groups)
{
if (grupa.ContainsCurrentUser)
{
label.Text += ” Należy do grupy:” + grupa.Name;
}
}

}
}

Przy zmianie środowiska dev na windows 2008 r2 z windows 2003, przy próbie publikacji webparta bezpośrednio z Visual Studio 2008 wyskoczył mi powyższy komunikat.

Dodam, że przy tworzeniu webparta z wizarda, wybrałem full trust (GAC deployment).  Żadne próby typu “Uruchom jako Administrator” nie zadziałały, fakt, że recznie przez gacutils mogłem dodawać, ale przy testowaniu nowego webparta jest to dosyć żmudne.

Sprawdziłem w IIS na jakim użytkowniku działa sobie pula aplikacji VseWss  (W menadżerze IIS -> Application pools).

Próbowałem dodać tego użytkownika do lokalnych administratorów, nie pomogło. Doczytałem chwilę poźniej, że musi on być dodany do grup: WSS_ADMIN_WPG, WSS_RESTRICTED_WPG.  Po dodaniu zadziałało!