Jeg har tidligere lavet et indlæg, som handler om at optimere tabellen AsyncOperationBase (Optimering af tabellen AsyncOperationBase...hvorfor og hvordan?). Dette indlæg er meget teknisk, og meget af arbejdet udføres på SQL Serveren.

Med jævne mellemrum bør man analysere Arbejdsprocesser (workflows), for at se om de gennemfører sit arbejde, eller om de er i en tilstand hvor de venter, og nok så vigtigt...om der er opstået fejl i forbindelse med arbejdsprocessen.

En del har kontaktet mig, og spurgt, om det er muligt at finde frem til Arbejdsprocesser (workflows) som indeholder fejl direkte fra MS CRM. Det har jeg så lavet et indlæg om: Finde Arbejdsprocesser (workflows) med fejl...

Den 17. december 2010 blev Microsoft SQL Server 2005 Service Pack 4 RTM frigivet. Denne Service Pack har voldt mig lidt problemer i relation til MS CRM. Problemer som absolut skal løses, da det påvirker eventuelle Maintenance Plan i relation til MS CRM. Problemerne kan nemlig forårsage, at der ikke bliver lavet backup af MS CRM, hvis det indgår i en Maintenance Plan (hvilket det bør gøre).

Jeg har lavet et indlæg om problemstillingen og løsningen herpå...

Tabellen AsyncOperationBase er en form for log, som med tiden vokser sig rigtig stor, især hvis man har mange arbejdsprocesser (workflows) kørende. Enhver hændelse omkring arbejdsprocesser bliver registreret og det fylder.

Man kan antage den holdning, at når en arbejdsproces er fuldendt som en succes, er der ingen grund til at man gemmer en sådan information i årevis. Dog kan informationen være nyttig i en periode, da den jo dokumenterer en hændelse.

Jeg har netop arbejdet for en kunde som havde en organisationsdatabase (<organisation>_MSCRM), som havde en størrelse på knap 33 GB, hvor tabellen AsyncOperationBase alene fyldte godt 16 GB. Der var godt 24 millioner poster i tabellen. Tabellens størrelse påvirker ydelsen dramatisk.

Jeg har lavet et indlæg om optimeringen: Optimering af tabellen AsyncOperationBase...hvorfor og hvordan?...

Fra tid til anden støder jeg på virksomheder, som har problemer med med at afinstallere MS CRM til Outlook, med det formål at gennemføre installationen igen - altså starte på en frisk.

Jeg har lavet en detaljeret beskrivelse af hvordan man laver en komplet fjernelse af MS CRM 4.0 til Outlook, som er installeret med offline-adgang, med det formål at kunne gennemføre en ny installation, uden først at skulle geninstallere operativsystemet. Læs mere i indlægget Komplet fjernelse af MS Dynamics CRM til Outlook...

Man skal passe på hvilken kode man indsætter i OnSave-eventen på formularer. I visse tilfælde kan det give en fejl når man f.eks. forsøger at genaktivere objekter, som f.eks. objektet Sager, og det er netop hvad dette indklæg handler om. Læs mere om problemet og løsninger herpå...

MS CRM har en fantastisk funktionalitet i Hurtig søgning, altså muligheden for at søge på kriterier.

Men den fantastiske Hurtig søgning har en begrænsning. Det er ikke muligt at søge i Inaktive eller Afsluttede elementer, såsom et Deaktiveret Firma, Produkt osv.

Det er heller ikke muligt at søge i en Løst Sag...dog kan det lade sig gøre, med en usupporteret metode. Læs mere om problemet og løsningen...

En analyse af en kundes MS CRM 4.0, hvor der var en del problemer med bl.a. import af data fra et eksternt system ind i MS CRM. En analyse af Event Vieweren indikerer problemer omkring vedhæftede filer eller noter...men det var ikke tilfældet. Læs om problemstillingen og løsningen...

Hvis man ikke kan ændre ændre visninger på objekter, f.eks. Firma, Kontaktpersoner mv., såsom at indsætte kolonner, flytte eller slette disse. Er det på grund af nogle ekstra sikkerhedsindstillinger i Internet Explorer. Hvilket ofte forekommer hvis man benytter MS CRM direkte fra Windows Serveren. Læs om problemstillingen og løsningen herpå...

Når man installerer Outlook til MS CRM på en maskine, som har flere Outlook-profiler installeret, kan der opstå problemer...og hvorfor så det?

Når man konfigurerer MS CRM til Outlook gøres dette i forhold til den profil, der er angivet som standardprofilen i Outlook. Hvis denne profil ikke er lig med brugerens login-profil til computeren, kan man ikke benytte MS CRM i outlook...hvorfor ikke?

Når man anvender MS CRM fra Outlook, benyttes Internet Explorer (IE) til at skabe adgangen til MS CRM, i forhold til den profil Outlook anvender. I det tilfælde, at den anvendte Outlook-profil ikke er lig med login-profilen vil IE forsøge at foretage login til MS CRM, med en bruger som ikke findes i MS CRM...og den går jo ikke.

Løsningen er enten:

• at fjerne de profiler, som ikke benyttes, så der kun er den "rigtige" profil tilbage
• eller indstille Outlooks standardprofil til den, der svarer til brugerens login til computeren

Ved flere lejligheder er jeg stødt på problemer med installation af MS CRM eller konfiguration af Outlook op imod MS CRM, hvor problemet var, at der indgik et underscore (_) i servernavnet på MS CRM Serveren.

Problemet med Outlook løses ofte ved at anvende IP-adressen til MS CRM Serveren (f.eks. http://192.168.0.10:5555). i stedet for brug af servernavnet (http://mscrm:5555), hvilket godt nok løser problemet indenfor organisationen, men efterlader et problem for Offline-klienter. Synkroniseringen vil ofte fejle.

En af mine kollegaer stødte på problematikke i dag, hvor det handlede om, at det ikke var muligt at tilknytte brugere til en nyinstalleret MS CRM, selvom der ingen problemer var med at se brugerne i Active Directory (AD).

I MS CRM implementeringsguiden står der, at Servervanvet ikke må starte med underscore (_) eller et tal. Der burde stå, at servernavnet ikke bør indeholde underscore (_).

Det er selvfølgelig kedeligt at få en fejlmeddelelse omkring data på SQL Serveren såsom denne:

Host SQLSRV012: error while processing organization c99bfbfa-4253-de11-bd20-001e0bbc75ef. Exception: System.Data.SqlClient.SqlException: Transaction (Process ID 67) was deadlocked on lock resources with another process and has been chosen as the deadlock victim.

Hvad betyder den, og hvad kan vi gøre ved den? Læs mere i indlægget om Transaction deadlocks...