Friday, January 14, 2011

Permissions to SQL Database

I have been working on the problem of Synchronization two vendor databases (to be particular – Symantec Endpoint Encryption (SEE) Database should be synchronized with Symantec Altiris Management Platform – former Notification Server Database). The synchronization did not work. What turned out to be a cause of the problem was a permission issue. I figured that Altiris Server (not an any user account) must have permissions to SEE Database. I added DomainName\AltirisServerName$ to the Users in the Security section of SEE Database with db_datareader and db_datawriter roles and synchronization started working.

Monday, October 4, 2010

Restart the domain controller in Directory Services Restore Mode Remotely

Extremely useful article when you need to boot domain controller into Directory Services Restore Mode Remotely:

http://technet.microsoft.com/en-us/library/cc779687(WS.10).aspx

Assign permissions to the tree of OUs when inheritance turned off (through Powershell)

Recently I needed to add permission to move computer objects to OUs for the group of users. I added the permissions to the “root” OU and tested it: everything worked great.
After I reported that task is done, I heard from the users in that group that they still get ‘Access is denied’ trying to move computer objects. I discovered that in AD permissions inheritance was disabled for most of the sub-OUs. So, there are more than 1,000 OUs to add permissions to.
Following script took care of the task for me:
#Require Quest "Active Roles Management Shell for Active Directory".

#Put following to the text document saved as *.ps1:

add-PSSnapin quest.activeroles.admanagement
$OU = “root OU DN”
get-qadobject -searchRoot $OU -searchScope 'SubTree'-Type organizationalUnit -SizeLimit 0 |
Add-QADPermission -Account “domainname\user group to add permissions” -Rights CreateChild -ApplyTo All -ChildType
Computer

Wednesday, August 11, 2010

Email Router for CRM4 and multi-server environment

We discovered interesting issue with email router when there are few (more than one) CRM4 Servers connected to the same database.

All CRM components in multi-server environment work independently: all requests are being fulfilled by the particular server to which server user connects.

Except e-mails (and mail merge).

Email Router happens to work only on the first CRM server in the environment.

Let me explain a little further:

Let's say you have 3 CRM servers: server1, server2, server3 connecting to the same database. They are combined to the server farm by the load balancer. "Virtual" name of the farm is crm.yourcompany.com. Users access CRM using "virtual" name: http://crm.yourcompany.com.

User requests are answered by one of 3 servers (server1 or server2 or server3) – directed by load balancer.

Let's say, user connects to server3, opens Contact and selects 'Send E-mail'. User fills email fields and click 'Send'. You would expect that email router on server3 processes that email. You would be wrong – email gets processed by email router on server1.

(I wonder what will happen if server1 goes down – would it mean that there will be no email processing by email router? – to me it looks like a single point of failure – hello, Microsoft…)

Monday, August 9, 2010

Email issues in CRM4 (various) – tips of fixing.


 

Symptoms:

Can't start Microsoft CRM Email Router Service

Emails are not sent stuck in 'Pending Send' – both regular and Mail Merge.

Cause:

Following file got corrupted:

Microsoft.Crm.Tools.EmailAgent.SystemState.xml

Fix:

2 options:

Either replace that file with the file from "working" CRM server (if you deployed multiple CRM Servers connected to the same database),

Or delete that file – restart should re-create the file


 

After the fix: re-start the 'Microsoft CRM Email Router Service'

Tuesday, June 29, 2010

Web site of the sister-company went live!

www.tacklesoftware.com went live. Home of the brand new Recycle Bin for Microsoft Dynamics CRM4. Product adds easy recovery to CRM4. Other CRM Tools to come. Good luck to the new web site!

Monday, June 21, 2010