Using RSWindowsNegotiate will result in a Kerberos authentication error if you configured the Report Server service to run under a domain user account and you did not register a Service Principal Name (SPN) for the account.

which actaully appears in your system event log as;

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server $NAME. The target name used was HTTP/$NAME. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using.

Right so to see the state of play, jump on a server with the DC roles and run;

ldifde -d “dc=$yourdomainhere” -r “servicePrincipalName=http*” -p subtree -l “dn,servicePrincipalName” -f output.txt

The contents of your output.txt should look something like this depending on your environment;

dn: CN=Administrator,CN=Users,DC=$domain
changetype: add
servicePrincipalName: http/$hostname
servicePrincipalName: HTTP/$hostname.local
servicePrincipalName: MSSQLSvc/$hostname

okay so to avoid the event id 4 error you need to ensure that the SPN is set correctly (ie matches the DC) on the host with the error. To check what the SPN is for the service account run setspn -l domain\account this will tell you what SPN’s are setup for that account, you can also do setspn -l hostname to see whats registered for the host.

Typically you will have to add a SPN to make the error go away so run setspn -a http/$name domain\account where $name is the target as it appears in the error message and account being the service account you are using.

When deploying the Ax09 SRSS Reports you may encounter the following;

Error: Deployment failed unexpectedly with the message:
Not found
See the log file for further details.
Deployment failed with the following exception:
System.Management.ManagementException: Not found

To counter this you need the hotfix located at;

https://mbs.microsoft.com/knowledgebase/KBDisplay.aspx?scid=kb;en-us;957312

Still on the SRSS Ax09 path, the .Net Business Connector was throwing an auth failure. I tracked this down to WSS loopback check.. this does not happen in my MOSS environment.

Anyway to fix it you have to;

In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

Right-click MSV1_0, point to New, and then click Multi-String Value.
Type BackConnectionHostNames, and then press ENTER.
Right-click BackConnectionHostNames, and then click Modify.
In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
Quit Registry Editor, and then restart the IISAdmin service.

Okay so two things this morning, still playing with SRSS AX09 reporting and in the application event log I note;

Dynamics Adapter LogonAs failed.

Microsoft.Dynamics.BusinessConnectorNet.NoIISRightsException
at Microsoft.Dynamics.BusinessConnectorNet.Axapta.Logon(BC_PROXY_ACCOUNT_INFO* pBCProxyAccountInfo, String company, String language, String objectServer, String configuration)

Now the important bit is the first line, this is not a standard auth error which I will get to in the next post… when I checked our License codes under the web tab, I see we don’t have EP Framework, now this is a base part of a AX2009 License so if you buy AX09 now you will have it. What happened here was that since we have been long time Ax users and our license codes have been upgraded Microsoft just plain forgot to include all the new bits which are required to run a Ax 2009 implementation.

I went to install SQL 2008 SRSS on one of our webservers this afternoon and kept getting told that it was failing the reboot pending check. After a bit of digging this seemed to have been caused by a visual studio devel install leaving crap in the registry, namely;

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

Delete any value in the key then hit the rerun button and you are good to go.

This morning I installed Service Pack 1 into our development Dynamics Ax 2009 systems as part of our upgrade project. I noticed shortly after this that I could no longer get into the the database log. Instead I got the error message;

“Not enough rights to use table ‘Signature log’ (SIGSignatureLog).”

Sp1 creates a new key called Electronic Signature, that you need to enable through Administration -> Setup -> System -> Configuration

Once it’s enabled all is well, now lets see what else I can find this week.

So I’ve been out of the hospital for a couple of days and my mother is doing some shit for her brother and needed a hosting account setup. Easy will take me all of 5 minutes to setup and install Joomla for them.

Well no fucking wrong, me being a dumbass and having no business working on anything at this point in time didn’t check what directory I was in, and instead of deleting the new accounts public_html folder I managed to delete my own. This is why the site was down a couple of hours while I sorted the backups being sent to me.

This reinforces two things for my mind, 1) backups are a good thing and 2) never touch something important after just having surgery and getting 7 holes put in your chest and stomach.

After the little hickup with ESXi I was running late so I kicked off the installation of Windows 2008 Enterprise server and left an instruction with my junior to put it on the domain, run the updates and activate it. I then went off to my afternoon of meetings, when I returned I was informed they couldn’t activate it as DNS was broken.

Like hell it is came my reply, to which I was shown the error message;

But wait there’s more information.. awesome;

Ok so it mentions DNS, but really this has got to be another case of Windows running home to mummy and just throwing out a random error and of course it is. This error comes about if you use Volume License media for your installation. To fix this you actually have to change your product key, and supply the correct MKS key from your agreement.

Providing the correct key magically makes the DNS issue go away and it’s all smiles again.

Yesterday as part of our ERP upgrade project I thought I would pilfer some of the new kit Dell has sent us, namely a MD3000i and a Poweredge 2950 and setup a ESXi enviroment. This way I can quickly deploy the new version of our ERP so the developers have something to work with while we get the real environment sorted out over the next couple of weeks.

Now I gotta admit this took wayyyyyy longer then it should of, ie 4 hours instead of 20 minutes. As with most things in IT there are some gotcha’s you have to be aware of, and wow did I find a gotcha. After an hour of frustration I was beginning to swear at Dell and the MD3000i as I was blaming it for the slow progress, I must have reconfigured that sucker a dozen times. Then I got a bum steer from a mate that told me the MD3000i needed it’s out-of-band management port in the same subnet as the iscsi ports to handle the chap… wrong!!!

With that I decided to fire up my trusty opensuse notebook, and within 10 seconds I had it connected to the iscsi lun I was presenting from the MD3000i. This was a WTF! moment.

At this point I was scratching my head and started swearing about ESXi, so I reconfigured it again, same result the MD3000i was seeing it’s SW initiator, but ESXi was not seeing the lun I was presenting it… this is where the God of IT “Google” steps in and I happen to come across a forum almost unrelated to my issue but in one of the threads I see a post from a guy complaining that ESXi unlike ESX won’t see a lun with a size greater then 2TB.

In ESX it’ll see the lun but you can’t format it from storage management as vmkfs has a 2TB limit, in ESXi the lun simply doesn’t appear. So the second I went back into the MD3000i and mapped a lun less then 2TB to ESXi it came up, previously I was presenting a 6TB lun. This has be kinda bummed as I wasted a fair chunk of my time on a simple gotcha, and while it’s my fault for not reading *ALL* the documentation on ESXi, I had read the Dell – VMware guides plenty in the 4 hours and none of them mentioned this.

I will hope and pray VirtualBox can mature and develop a nice bare metal hyper visor as well. As an aside the Dell MD3000i works like a charm, I have since tested it with VBox, VMware Server 2.0 and it plays nice there and no lun size issue.

I had a few spare moments the other night while I was upgrading our mail server so decided to have a look at the Windows 7 Beta I had installed earlier on virtual box.

While I was doing some benchmarking I happen to get an error on copying a file and couldn’t help but laugh.

Now I figure this is actually a CRC error as the file I was copying was incomplete, but I guess I now know Microsofts plans to improve copy performance in Windows 7, they are going back to dos.