My laptop has two hard drives — a 128GB SSD and a 1TB old school hard drive (taking the place of the DVD drive, which I never used). I love the SSD, but it’s size limits it to the operating system, some important program files, and a handful of documents.
Every now and then, it fills up. I recently found a silent disk space usage offender: Microsoft’s Web Platform Installer. Apparently, the Web Platform Installer (WebPI) caches all installer files to a local folder, and never deletes them. Which isn’t a problem if you have plenty of disk space, but for me, it’s a problem.
The path to the WebPI installer cache folder is “%LOCALAPPDATA%\Microsoft\Web Platform Installer\installers” – where the variable LOCALAPPDATA points to a folder in your user profile directory. For example, on my machine, the full path is C:\Users\demarzo\AppData\Local\Microsoft\Web Platform Installer\installers.
Deleting all the files in this folder is safe, as the WebPI will simply re-download what it needs when it needs it, which should be perfectly fine for most people who don’t make a habit of repeatedly reinstalling the same version of software over and over again. For me, it saved over 1GB of disk space. Which tells me, among other things, I install a lot of software!
Lots of tables in Dynamics CRM use the ObjectTypeCode to identify the entity. Sure, we all remember that Account is ObjecTypeCode 1 and Contact is ObjectTypeCode 2… But what about your custom entities, which start at 10,000 and are not guaranteed to be the same in different organizations, even if you have the same solutions installed — how will we remember their ObjecTypeCode values?
You don’t remember them, you query them when they need you. It’s quick and easy if you are on premises and have access to the SQL database. (If you don’t, ask your DBA to create a view with this query and give you rights to it.)
select coalesce(OriginalLocalizedName,name) as DisplayName, Name as SchemaName, ObjectTypeCode
order by ObjectTypeCode
Much easier than memorizing, and avoids the problems of remembering the wrong number for the wrong organization or deployment. Oops!
Microsoft Dynamics CRM 2011 allows us to specify relationships between entities, and gives us some configuration as to how those relationships work. One of those relationship types is “parental” — which effectively means, “anything that happens to the parent happens to the child.” Therein lies a lot of power — and a lot of risk.
In the environment where I work, we have a lot of entities. Two of those entities are a “Contract” entity (not the out-of-the-box Contract entity, which we renamed to a more appropriate “Service Contract”) and a “Contract Volume” entity. Intuitively, since you can not have Contract Volume without a Contract, we set the relationship type to parental, with Contract being the parent to Contract Volume.
We have thousands of Contract records, and hundreds of thousands of Contract Volume records. The data for these comes from a separate proprietary application. Data is inserted/updated . . .
→ Read More: How entity relationships can kill performance in Dynamics CRM 2011
I’m going to make an announcement that may come as a shock to anyone who knows me…
I’ve voluntarily decided to give up coffee.
Those that know me will probably react like the first person who saw me walking around today with a cup of water instead of a cup of coffee: they laughed. I was a heavy coffee drinker, about 5 cups a day. I enjoyed my coffee. I blogged about the wonders of coffee. I identified myself with a cup of coffee. I bought coffee for co-workers, and they bought it for me. I went out for coffee breaks when the smokers went out for cigarette breaks. I looked forward to drinking coffee…
So why the change? Ultimately, it came down to health and stress. I drink too much coffee (caffeine) and not enough water, and I’ve been too stressed lately. Coffee (caffeine) is not helping either of those.
After writing that, I decided . . .
→ Read More: First day without coffee… or not?
Some would wonder why such a question is asked… but in my Microsoft Dynamics CRM 2011 environment, we do not require a First Name or Last Name on a Lead. When a Lead is qualified, users often click the buttons to create an Account and a Contact, even when they haven’t specified any contact-specific information (such as first and last name). What results is often a Contact with no name, and that contact is the Primary Contact for the Account. Ouch!
To fix this, we created a workflow on the Contact entity, which would deactivate the Contact if it had a Qualifying Lead, and had a blank First Name or Last Name. This took care of the Contact, but there was still a problem: the Account’s Primary Contact pointed still pointed to the nameless Contact we just deactivated!
Looking at the Audit History on the Account, we were able to figure out that, when . . .
→ Read More: Getting rid of nameless Contacts when Leads are qualified in Dynamics CRM