So I've just had the domain of my dev PC changed, and at first glance I thought that everything on my profile had come across nicely via MS's lovely transfer wizard (not roaming). My desktop was there, my backdrop was there... lovely. But then I noticed the little irritating things that hadn't come across, such as:

• Start Menu
• Quick Launch
• Lanugage Bar settings
• Email signatures

Thankfully most of them can be re-done pretty quickly (for example, just copy your Signatures folder from the Microsoft\Signatures folder in your Documents and Settings profile to your new profile) but it is a waste of time. Imagine what it would be like moving a whole office across domains, especially if the office aren't that IT literate. An hour assisting each person would quickly rack up to weeks of work.

If anyone knows of a better 3rd party tool to move profiles across when domains change, do let me know! :)

When using EPiServer, especially when using it on a local dev PC, you may get an error such as:

"The trust relationship between the primary domain and the trusted domain failed"

EPiServer have a post about the error here, but they are only talking about a full server install environment. If you're using it locally, then it's more likely that you're just using a domain account to log on, when in fact you should be using one of the internal EPiServer user accounts. I confused myself by creating a 'soft' account called 'admin' and then wondering why I was getting the error... I was logging in as 'administrator' which is of course a full NT account :)

So the purpose of a Use Case is for an 'Actor' to successfully complete a 'Goal'. Fair enough. But... what if you have a Use Case like the following:

Name: Hacker Compromises The Site
Primary Actor: Hacker
Success Criteria: Hacker obtains unauthorised access to the site
Failure Criteria: Hacker cannot obtain access to the site

Is this a valid Use Case for your system and, if so, then is a Success actually a system Failure? Is this just a logical paradox or a real problem? Would you just word it as follows instead?

Name: Prevent Site Hacking
Primary Actor: Hacker
Success Criteria: Hacker cannot obtain unauthorised access to the site
Failure Criteria: Hacker obtains unauthorised access to the site

Is this just sidestepping the problem? Is it not a good Use Case because the goal should always reflect the success criteria of thePrimary Actor?

Answers on a postcard please. Or just a comment will do :)

So it was decided that it was worth getting myself and one of the guys on my team actually certified on SharePoint - probably a good idea!

Looks like it's not going to be a rubber-stamping of what we already know though - the course is one of these condensed 5-day blitzes where you eat, sleep and work the course. Yikes. It's not the stuff I normally do anyway, as it's the professional rather than developer perspective and I tend to get my mitts stuck in the API more than the other things. I think I'm going to learn lots and very fast.

It's a bit daunting but it should be good though. Good for us, good for the business. Plus, as a Microsoft Gold Partner, we got it a little cheaper :)

The one we're on will be run in September by Training Camp UK. I think Microsoft are sponsoring it so it's not available through the main Training Camp UK site, but it's this course.

You may see an error when installing EPiServer using EPiManager 1.3.2:

"This setup requires the .NET Framework version 2.0.50727..."

Which is fine... except that if you ONLY have .NET 2.0 installed and not .NET 1.1, then you still get the error! It seems as if EPiServer has patched their EPiManager, but it still seems problemmatic.

Easiest thing to do is probably just install the .NET 1.1 runtime. Remember to ensure the default is .NET 2.0 afterwards in IIS.

I've found a little glitch (by design?) in ADXSTUDIO 2006. The scenario is this... I want to give an 'Approvers' group access to approve across the whole site except for a 'Sensitive' folder, that can only be approved my managers.

According to ADXSTUDIO, the way to do this is to explicitly GIVE permissions to the Approvers group everywhere except where I don't want them to have permissions. Yeah right. It's a big site :)

You might think 'no probs, I'll just DENY them access to that one folder'. Nice, in theory... but in practive it spams out a nasty error when you try to do that. I guess it can't handle deny-access being added to an object with grant-access set on it as well (albeit inherited).

Solution? Resort to ADSIEdit. Locate the Sensitive folder within the AD object hierarchy (no, not easy) and take off the inheritance of permissions. I suggest copying the existing permissions otherwise you'll have fun adding them all in. Then just strip everything but read permissions away from the Approvers group.

Now, when someone in the Approvers group tries to edit pages in the Sensitive folder, they get an Access Denied error. In the rest of the site, they are able to edit pages.