I was lucky to attend and present at last week’s SharePoint Best Practices conference. I’m still new to the whole speaking "thing" и, искрено, I was a bit nervous for the first half while I sweated out waiting to speak myself. That sort of nervous feeling made it a little hard for me to pay attention to the presenters (не дека јас ги игнорира). Наместо, Јас се фокусираше малку повеќе на присутните.

Conferences always set my mind racing and there was a lot take in at this one. This conference was excellent. I think it was unusual in several ways. It wasn’t a heavy developer conference. There were certainly dev parts to it, но мислам дека тоа беше најмалку 60% фокусирани на не-dev прашања, maybe as high as 80%. I think that speaks to the evolving nature of the SharePoint market. Companies are implementing SharePoint in a variety of ways and they are looking for guidance on how to do it right. And not just guidance on how to create features/solutions (кој до сега, е многу добро воспоставена).

I believe the conference was tremendously valuable to most everyone that attended and I know that the organizers plan to do the conference again early next year.

Кој рече дека, I believe there was a missed opportunity which I hope the next conference addresses. I say it’s a missed opportunity, but that’s not a bad thing. Discovering a community need is in and of itself a good thing. The conference discussed a number of best practices in a variety of areas such as governance, обука, барања собир, пребарување, развој, информации архитектура, итн. I think that the missed opportunity has to do with the "green field" претпоставки кои многу од најдобрите практики.

Кога зборуваме за гринфилд, we mean that SharePoint hasn’t gone into production and we’re starting with a clean slate. This is ideal because you can start straight away using best practices for defining and managing governance, информации архитектура, итн. Сепак … она што се случува кога сте веќе во производството со неколку илјади корисници (or 10’s of thousands) и ти не го следат најдобрите практики на почетокот? I’ve seen companies with … ahem … многу чудно information architecture baked into their environment. I don’t think that this conference provided much guidance for organizations with that kind of problem (и јас не само значи IA, но владеење, пребарување, многу други области). Се разбира, знаејќи дека имаат проблем е голем дел од решението, а тоа е многу важна.

I think that the online SharePoint community hasn’t done much to address this either. I know I have not. It’s a very hard problem to solve at many levels. Technically it’s hard. Budget-wise it’s hard. Culturally, it’s hard. Сепак, it’s probably a bigger real world problem than most. Since the conference ended, I’ve been thinking about these kinds of problems and how one would solve them. There has to be a better answer than, "uninstall and reinstall" и заедницата треба да се соочиме со тоа главата на.

I think that this a great opportunity for the blogging community and experienced thought leaders to lay out some guidance on how to repair their environments. I think there’s a small but non-zero risk that SharePoint could end up with a bad and enduring reputation as a result of poorly architected implementations that fail due to poor governance, IA, итн.

</крајот>

Да се ​​претплатите на мојот блог.

Мојата онлајн пријател, Марк Милер одново и Крајниот корисник SharePoint (www.endusersharepoint.com) е водење на слободна еден час семинар насочени, како што секогаш го прави, at the SharePoint End User community. It takes place at 1pm EDT. Details are here: http://www.endusersharepoint.com/?p=785

Сум седел во еден од неговите онлајн семинар минатиот месец и тоа беше направено доста добро и ако сте заинтересирани за некои многу практични информации за DASHBOARDS во SharePoint, Сигурен сум дека тоа е вредно за 1 час инвестиции.

</крајот>

Да се ​​претплатите на мојот блог.

My colleague has been working on a web part in an FBA environment. Among other things, the web part pulls some data from SQL server. The grand plan for this project dictates that a DBA configures data level security in SQL (што е спротивно на внесување на корисничко име во барањето SQL или некои други пристапи).

The problem is that SQL server doesn’t know anything about our FBA environment so it can’t trust us. We solved this problem by, поради недостаток на подобар збор, manually impersonating an AD user so that we could connect to SQL such that SQL data level security works.

Иако FBA е карактеристика ASP.NET, ние SharePoint нацијата луѓе се предава на различни пребарувачи дека ако сте доведување во прашање за FBA, you must mean you want know how to configure FBA in SharePoint. I failed to find find any information on how to enable an FBA oriented ASP.NET application to communicate with SQL in the way we needed.

Во текот на истражување на овој, ние повторно ја прочитате оваа статија: ASP.NET присвојување

Повеќе истражувања нè доведоа до оваа статија codproject: http://www.codeproject.com/KB/cs/cpimpersonation1.aspx

Кој ни помогна да пишува нашата код, which I’ve included below. It’s not the most elegant stuff, но тоа работел. I hope you find it helpful.

Еве го кодот што работеле за нас:

заштитени празнина btnSearchCarrier_Click(објект испраќачот, EventArgs e)
 {
 обидете
 {
 ImpersonateUser IU = нови ImpersonateUser();
 // НАПРАВИ: Замени ингеренциите
 ("DomainName", "UserName", "Password");

//
 КОД
//

 iU.Undo();
 }
 фати (Исклучок екс)
 {

 }
 }

// Користење на присвојување класа како што е споменато подолу.

јавноста класа ImpersonateUser
 {
 [DllImport("advapi32.dll", SetLastError = вистина)]
 јавноста статички однадвор bool LogonUser(
 Стринг lpszUsername,
 Стринг lpszDomain,
 Стринг lpszPassword,
 int dwLogonType,
 int dwLogonProvider,
 РЕФ IntPtr phToken);

 [DllImport("kernel32.dll", Charset = CharSet.Auto)]
 приватни однадвор статички bool CloseHandle(IntPtr рачка);

 приватни статички IntPtr tokenHandle = нови IntPtr(0);
 приватни статички WindowsImpersonationContext impersonatedUser;

 // Ако се вклучат овој код во DLL, не заборавајте да побараат тоа
 // работи со FullTrust.
 [PermissionSetAttribute(SecurityAction.Demand, Име = "FullTrust")]
 јавноста поништат игра улогата(низа именадомен, низа корисничко име, низа лозинка)
 {
 обидете
 {

 // Го користите на Unmanaged LogonUser функција да добие на корисникот знак за
 // наведениот корисник, домен, и лозинка.
 const int LOGON32_PROVIDER_DEFAULT = 0;

 // Донесувањето на овој параметар предизвикува LogonUser да се создаде основни знак.
 const int LOGON32_LOGON_INTERACTIVE = 2;
 tokenHandle = IntPtr.Zero;

 // Чекор -1 Јавете се LogonUser да се добие рачка на токен за пристап.
 bool returnValue = LogonUser(
 корисничко име,
 име на домен,
 лозинка,
 LOGON32_LOGON_INTERACTIVE,
 LOGON32_PROVIDER_DEFAULT,
 Сопственост tokenHandle); // tokenHandle - новите безбедносни знак

 ако (лажни == returnValue)
 {
 int изгнивам = Marshal.GetLastWin32Error();
 Console.WriteLine("LogonUser call failed with error code : " +
 право);
 фрли нови System.ComponentModel.Win32Exception(право);
 }

 // Чекор - 2
 WindowsIdentity newId = нови WindowsIdentity(tokenHandle);
 // Чекор -3
 impersonatedUser = newId.Impersonate();

 }
 фати (Исклучок екс)
 {
 Console.WriteLine("Exception occurred. " + ex.Message);
 }
 }


 /// <резиме>
 /// Запира имитирање
 /// </резиме>
 јавноста поништат Поништи()
 {
 impersonatedUser.Undo();
 // Ослободи токени.
 ако (tokenHandle != IntPtr.Zero)
 CloseHandle(tokenHandle);
 }
 }

</крајот>

Да се ​​претплатите на мојот блог.

Неколку недели назад, I was working with my developer colleague on a project involving SQL Server Reporting Services plug-in for MOSS. He was developing a web part that provides a fancy front-end to the report proper (главната карактеристика да се биде умен Пребарување на параметар со неколку илјади пребарува вредности зад неа).

Тоа беше работа одлично во развој на животната средина, но во корисник прифаќање тестирање (UAT) животната средина, it wouldn’t work. Firing up the debugger, ние ќе ја видите исклучок детали како овој:

На дозволите доделени на корисникот UAT_domain mosssvc "не се доволни за вршење на оваа операција.(rsAccessDenied).

Ако го направите во живо пребарување на погоре грешка, you find it’s quite common. Scarily common. The worst kind of common because it has many different potential root causes and everyone’s suggested solution "feels" право. We probably tried them all.

Во нашиот случај, the problem was that we had done a backup/restore of DEV to UAT. Somewhere in the data, something was still referring to "DEV_domain" (instead of the updated "UAT_Domain"). We created a new site, додадени веб дел и дека реши нашиот проблем,.

Се надевам дека ова ќе заштедите некој еден час или два по ред.

</крајот>

Да се ​​претплатите на мојот блог.

I receive a handful of messages from individuals via the built-in "send a message" функција Мајкрософт обезбедува со Live Spaces (кој исто така е домаќин на мојот блог) секој месец.

Околу една третина од времето, those users have secured their live spaces account such that I cannot reply. This is some kind of anti-spam feature I assume.

</крајот>

Јас го читав блог пост Madhur за тоа како да овозможи стекот дисплеи и сега се прашувам: зошто не можеме секогаш да се прикажуваат на стекот?

Кои дојдоа со тоа правило и зошто ние да го следат?

End users will know something is wrong in either case. At least with a stack trace, тие можат да притиснете контрола-printscreen, copy/paste into an email and send it to IT. That would clearly reduce the time and effort required to solve the issue.

</крајот>

Јас да направите пребарување на Google:

Јас кликнете на линкот нагласени погоре ("Детали за преземањето: Windows SharePoint…").

Јас се добие оваа:

Note the URL.

Looks pretty suspicious to me. I don’t know if I should laugh, кискане или јавете се на свештеник.

</крајот>

http://groups.google.com/group/microsoft.public.sharepoint.portalserver.development/browse_thread/thread/41e8cbe4f15e8b4c/76506ea401403e35?#76506ea401403e35

Ако ја алатката прави работи што не го разбираат, а потоа тоа не успее во чекор N на еден непознат број на чекори, ти си мртов во вода…

</крајот>

Ажурирање (04/08/08): I seem to have solved this problem. From the command line, I ran "c:\WINDOWS system32 lodctr / Р" како за влез зборуваме за InstallShield проблеми и дека се чини дека го имаат решено за мене.

Имам забележано дека во последно време, my desktop/server fan never turns off. I know it used to turn off. I took a moment to check it out noticed that the a VMware process was running a consistent 20% utilization on one of the CPU’s. I checked the event log and saw these errors in the application log happening dozens of times per minute:

Windows не може да се бутира растеглива контра DLL UGatherer, првиот DWORD на податоци дел е грешка на Windows код.

Windows не може да се бутира растеглива контра DLL UGTHRSVC, првиот DWORD на податоци дел е грешка на Windows код.

Windows не може да се бутира растеглива контра DLL MSSCNTRS, првиот DWORD на податоци дел е грешка на Windows код.

Ако јас се вежба во деталите на една од тие пораки, Јас се добие оваа:

Извор: Perflib

Тип: Грешка

Категорија: Никој

Настан проект 1023

I did some research and there was some indication it could be a permission problem in terms of access to the DLLs in question. I played around with that stuff but could not affect things in a positive way so I gave up on that.

VMware биле мене Досаѓање за вршење ажурирање за сосема извесно време, па јас jotted надолу верзија имав инсталирано (apparently "1.0.1 build 29996") and did the update. This upgraded me to v1.04. За жал, тоа не го поправат проблемот.

I can stop the insane number of messages going to my application log if I shut down a service named "VMware Authorization Service". This prevents me from using the VMware software, па … not such a great option.

На домаќинот оперативен систем е Windows XP 64 малку.

Јас не мислам дека ова отсекогаш се случи, но јас не се сеќавам некој посебен настан што би можело да доведе до тоа.

Ова е причината зошто јас мразам компјутери.

</крајот>

А колеги, "Mark", has started up a potentially interesting newsgroup discussion focusing on "establishing excellent SharePoint Governance from the start" за 35,000 корисник на животната средина.

Дискусијата е тука: http://groups.google.com/group/microsoft.public.sharepoint.portalserver/browse_thread/thread/6d9a738d981af772/1c390b15c5407db6?#1c390b15c5407db6

Поп на повеќе и да придонесе!

</крајот>