Ok so MS sent me a freebie copy of Windows 7 Ultimate last week and this weekend I decided to upgrade my vista test machine. First thing I notice is this new “homegroup” service they have included and in typical MS form there is no straight forward way to piss it and it’s persistant desktop icon off.

Thankfully they haven’t removed regedit yet so lets look in door number 3….

Computer\HKEY_LOCAL_MACHINE\SOFWARE\Microsoft\Wind ows\CurrentVersion\Explorer\Desktop\NameSpace\

There are a number of Keys here but the one of interest to us today is {B4FB3F98-C1EA-428d-A78A-D1F5659CBA93}. Export it, and then delete this key. Refresh the desktop (F5) and voila the homegroup icon is gone. This will not effect it’s actual use, so I would take this one step further by opening the homegroup settings and choosing the leave homegroup option.

Lastly go into your services.msc and disable the 2 homegroup services to prevent them running.

I had to export the Master Items from one company to another in differing databases as someone made a mistake with the Items and needed them restored, as there were a lot of other changes doing a straight up SQL DB restore wasn’t a good option. So anyway I created a new definition group and added the 3 tables I wanted (inventtable, inventtablemodule and inventitemlocation) to export in the source company, and then replicated that definition group in the target company.

From here you export the definition group to a file as binary this gives you 2 files a file.def and file.dat, one being the layout and the other the actual data. In the target company you then select the definition group and import validating and skipping existing records.

InventDim table won’t be necessary for this exercise as it is required when the InventDimId field on InventItemLocation is not “allBlank”. However should that field not be “allblank” you either have to add the InventDim table to your definition group for export/import or use a job to alter that field once imported to be “allblank”.

An example of such a job is;

static void MWD_UpdateInventDimIdInvItemLoc(Args _args)
{
InventItemLocation itl;
;
ttsBegin;

delete_from itl where itl.inventDimId != ‘ID00000635’;

update_recordset itl
setting
inventDimId = ‘ALLBlank’
where itl.inventDimId == ‘ID00000635’ &&
itl.dataAreaId == ‘ts1’;

ttsCommit;

info(“Processing Finished.”);

}

If you are getting a lot of Event Id 1030 errors that appear in the event log like “Windows cannot query for the list of Group Policy objects”. I recommend you remove badly stored domain credentials via the registry.

1. Run Regedit
2. Drill down to HKLM\System\CurrentControlSet\Control\Lsa
3. In the right pane locate the disabledomaincreds key
4. Change the disabledomaincreds value to 1 to stop store domain credentials.

Users will be presented with an error message regarding their profile and some applications may cease to function to correctly perform the following step to resolve;

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
3. On the Edit menu, point to New, and then click DWORD Value.
4. In the New Value #1 box, type PoolUsageMaximum, and then press ENTER.
5. Right-click PoolUsageMaximum, and then click Modify.
6. In the Value data box, type 60, click Decimal, and then click OK.
7. If the PagedPoolSize registry entry exists, go to step 8. If the PagedPoolSize registry entry does not exist, create it. To do this, follow these steps:
1. On the Edit menu, point to New, and then click DWORD Value.
2. In the New Value #1 box, type PagedPoolSize, and then press ENTER.
8. Right-click PagedPoolSize, and then click Modify.
9. In the Value data box, type ffffffff, and then click OK.
10. Exit Registry Editor, and then restart the computer.

once completed I recommend you install the HIVE cleanup service as well as ensuring your page file is 1.5 times the size of the hosts physical memory.

A mate rang me this morning as he received some new sunrays to add to his fleet (good man) but they wouldn’t boot with the 27B error. This stumped him as he as 30 odd sunrays already in use and working fine. I noticed in his DHCP server options he was missing 2 settings I use.

066 and 049, these should both be pointed at your Sunray 3.1 Server, they are definitely needed if you are booting your DTU’s over a WAN but can be optional on a lan but as seen here it’s not set in stone that it will work without issue on the lan. Better safe then sorry in my book.

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.