In Dynamics NAV it is possible to have multiple companies that have similar names. This is because Company Name is not a primary key. Person contacts may be assigned to one of the two companies. If one of these contacts is updated from Outlook, the person contact could be assigned to the other similar named company.
Let’s consider the following scenario:
As you can see, The Cannon Group PLC exists two times. If we create a new person contact and assign this to the second The Cannon Group PLC (CT000142), the picture would look like this:
After synchronization all contacts to Microsoft Outlook, it may sometimes be necessary to update one of the contacts from Outlook. If this is done for the Marco Mels user (CT000143), then after synchronization, the picture would look like this:
The reason for this issue is described below:
When something is modified from the Outlook side, the information sent by the Outlook Add-In to Dynamics NAV contains all the fields of the changed entry, not only the changed ones. On Dynamics NAV side, there is no validation that checks whether a field has changed or not. Therefore, it updates all the fields that have been sent by Outlook Add-In for a given entry. The company contact is mapped as a linked relation based to Company Name which is not a primary key. Dynamics NAV receives the Company Name from Microsoft Outlook. The update follows the condition definition and finds the first company with the given company name and uses this one to update the company ID. It can happen that this is the wrong one causing all sorts of incorrect behavior.
In order to fix this there are 3 options:
1) Enforce a unique key on the company name. In this particular name have the customer use a sort of convention for companies that have the same name, something like My Company (Berlin), My Company (Hamburg) ... so that names are unique 2) Only modify contacts from Dynamics NAV 3) Add Company No. to the CONT_SP so that the Company No. makes the linked relation unique
To do so, start up the Dynamics NAV client and select Administration, Application Setup, Microsoft Office Outlook Integration, Outlook Synch Entities, press F5 in Code field and select CONT_PERS. Now select Synch. Entity and select Fields. Add a new line and ensure field 50151 is selected and press OK. Furthermore, select User-Defined and save the changes. Do not forget to register the changes in the Change Log!
Drawbacks of this approach:
1) If they want to move a contact to a different company, you need to remember to change the Company No. as well 2) If you want to create a new contact in Outlook, you also need to add the number
Marco Mels CSS EMEA
This posting is provided "AS IS" with no warranties, and confers no rights
Brand new training titles have been released and are available on PartnerSource and CustomerSource (account required). The trainings are available as downloads and as instructor-led training (ILT).
Upgrading Microsoft Dynamics NAV 2009 Native Database to Microsoft SQL Server
This training is designed for individuals preparing to upgrade Microsoft Dynamics NAV 2009 Native database to Microsoft SQL Server. This training covers the upgrade process from preparing existing data, configuring Microsoft SQL Server, troubleshooting data issues, to validating data after upgrade.
Microsoft Learning: http://www.microsoft.com/learning/en/us/Course.aspx?ID=80298A&Locale=en-us
Microsoft SharePoint Technologies and Microsoft Dynamics NAV 2009
This training is designed for individuals who want to integrate Microsoft Dynamics NAV 2009 with Microsoft SharePoint technologies.
Microsoft Learning: http://www.microsoft.com/learning/en/us/Course.aspx?ID=80297A&Locale=en-us
Dynamics NAV Services (Web and RTC) are both WCF (Windows Communication Foundation) services and the tools used to troubleshoot WCF can be used to troubleshoot your NAV Services. The steps below can be used for both the NAV RTC and NAV Web service instances. A core feature of WCF is to allow trace logging to diagnose any problems you may encounter within the web service. Before jumping into creating a trace file for the NAV Web Service, some clarification on WCF tracing is in order.
WCF - Trace Listeners
WCF provides base "Trace Listeners" that can be used to capture specific events and output data to some medium. For instance, you can output trace results to a UI, file, or Windows event log. The three main types are:
Here are some of the core WCF Trace listener's provided by .Net and what they can capture:
Logs the following:
WCF - Trace Levels
WCF Trace Listeners incorporate a "Trace Level" that allows you to configure the level of tracing. Here are the levels and what they capture:
Unhandled exceptions including the following are logged:
In general, messages helpful for monitoring and diagnosing system status, measuring performance or profiling are generated. You can use such information for capacity planning and performance management:
In general, you can use this level for debugging or application optimization.
This level allows administrators and developers to correlate applications in the same application domain:
How to Enable Tracing with NAV
Tracing can be enabled by modifying the web service configuration file and the appropriate elements to alter the behavior of the service. The sample below provides a minimal level of tracing. As a minimum within the configuration file, you need to add a source, a listener, a listener type, and a location for the results. Below is a configuration snippet that is using the SystemService.Model Trace Listener with a listener of type "System.Diagnostics.XMLWriterTraceLister", and a location of "C:\Log\Traces.svclog" to log tracing events.
<configuration> <system.diagnostics> <sources> <source name="System.ServiceModel" switchValue="All, ActivityTracing" propagateActivity="true"> <listeners> <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData= "c:\log\Traces.svclog" /> </listeners> </source> </sources> </system.diagnostics></configuration>
Note, the "switchValue" refers to the "Level" of logging as described above. PropogateActivity allows you to correlate activity across endpoint(s), which is very helpful in correlating client to server communications. The type "System.Diagnostic.XmlWriterTraceListener" allows you to direct the tracing and debugging output as XML-encoded data. The file created has an extension ".svclog", which is a special file type reserved for use with the service trace viewer tool (which is part of the windows SDK).
To enable tracing for the NAV web service, all we need to do is update the NAV configuration file with the diagnostic elements so that we change the behavior to emit trace results. To enable tracing for NAV, update the Microsoft.Dynamics.Nav.Server.exe.config file in your installation folder. Using the above snippet as a basis for a trace, you would end up with the following configuration. (Make a backup of your configuration file before modifying!).
Microsoft.Dynamics.Nav.Server.exe.config (Before modification)
<?xml version="1.0" encoding="utf-8" ?><configuration> <appSettings file="CustomSettings.config" /> <system.diagnostics> <assert assertuienabled="false" /> </system.diagnostics></configuration>
Microsoft.Dynamics.Nav.Server.exe.config (After modification)
<?xml version="1.0" encoding="utf-8" ?><configuration> <appSettings file="CustomSettings.config" /> <system.diagnostics> <assert assertuienabled="false" /> <sources> <source name="System.ServiceModel" switchValue="All, ActivityTracing" propagateActivity="true"> <listeners> <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData= "c:\log\Traces.svclog" /> </listeners> </source> </sources> </system.diagnostics></configuration>
The next step is to ensure that the user or service that is running your Dynamics NAV Service has rights to write to the "C:\log\" directory. Create the directory if you don't already have it and apply security rights to the user or service identity currently used for your Dynamics NAV web service.
The last thing to do is to simply restart your NAV web service to enable the new configuration. Note: the Dynamics NAV Service and the Dynamics NAV Web service use the same configuration when starting up the service, so stop the Dynamics NAV Service to isolate the trace to only web service specific activity. When you start NAV web services, you should see a trace file in the "C:\Log" directory. To view the trace file, use the Service Trace Viewer tool (SvcTraceViewer.exe), which is installed with the windows SDK and can typically be found in the default location of "C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin". The amount of information in your trace file will depend on the tracing level you have defined. Typically I use the tracking event "All" so that I get all information from the trace listener. Please note the WCF will cache some of the trace results and will not flush out the trace elements entirely in real time. Once you have recreated the problematic activity with the trace running, you will need to stop the NAV Web service to flush out the entire trace results. The trace file is locked for writing until the service is stopped; at which time you can use the trace viewer to view the trace results. Using the trace viewer you can see the detail of any exceptions and then leverage that detail to help isolate the problem in the web service.
To disable logging, restore your original configuration file and restart your NAV web service. When performing tracing in a production environment, see the following link in MSDN for additional information:
Recommended Settings for Tracing and Message Logging in a Production Environment
In addition, here is a helpful link in MSDN that describes how to correlate activities between client and server along with using the trace viewer tool:
Best regards,Bert BurkholderNAV Escalation Engineer
Probably most of the partners have already noticed this and changed the C/AL code accordingly in order to let their customized application works properly.
In ALL versions of NAV up to now (NAV 2009 R2) the SORTING of Temporary Tables / Temporary record variables has always been determined using a C/AL sorting "collation" type. Even in SQL Server environment, where it is possible to select the proper collation (File > Database > Alter > Collation) for the database, Temporary Tables / Temporary record variables use always C/AL sorting order. This is very important to know since it may lead to a wrong business processing of data when using e.g. record looping (REPEAT .. UNTIL cycles).
This behavior has been maintained like this for 2 main reasons:1) Temporary Tables / Temporary record variables get created independent on the server, so they cannot read the collation and sorting from SQL Server and use this.2) If MS NAV Development team change the way that Temporary Tables / Temporary record variables are sorted, then this might break compatibility with a lot of existing solutions that would suddenly sort differently.Below you will find a simple demonstration of this assumption. For completeness, I have made the example both for Classic Client (Forms) and RoleTailored Client (Pages) but the behavior is the same.
1. Install a CRONUS database (W1 or whatever localized version)
2. Add these records in Table 6 "Customer Price Group"
3. Add and enable one key to table 18 Customer with "Customer Price Group" field (if this is not already active). Save and compile (CTRL+S) table 18 Customer.
4. Add those codes to Customers.
5. Create a New Codeunit, e.g. Codeunit 50000 "Test TempTable" with these global variables and code snippet:
Set the Temporary property of the CustTemp variable to Yes.
C/AL code snippet:
// Copyright © Microsoft Corporation. All Rights Reserved.
// This code released under the terms of the
// Microsoft Public License (MS-PL, http://opensource.org/licenses/ms-pl.html.)
Cust.RESET; // Populate CustTemp Table
Cust.SETCURRENTKEY("Customer Price Group");
Cust.SETFILTER("Customer Price Group",'<>%1','');
IF Cust.FINDSET THEN REPEAT
CustTemp.Name := 'TEMP ' + COPYSTR(CustTemp.Name,1,25);
UNTIL Cust.NEXT = 0;
Cust.RESET; // Run Page/Form - Normal table
IF ISSERVICETIER THEN
CustTemp.RESET; // Run Page/Form - Temporary table
CustTemp.SETCURRENTKEY("Customer Price Group");
6. Save and compile (CTRL+S) the codeunit.
7. Run the Codeunit. (You can also add this Codeunit as an action in RTC. The results within Forms and Pages is the same).
8. Now compare the 2 Forms opened (they are one up in front the other) and their different sort order (show column "Customer Price Group" to clearly see the difference in sorting order):
Since from the next version there will not be any support for Native database (where this C/AL sorting coming from) there have been speculations about changing this behavior in order to have the SORTING for Temporary Tables / Temporary record variables equal to the SQL Sorting (in short, for SQL Server based environments to have the same sorting order for normal tables and temporary tables).
If you think this is a remarkable feature that could / should to be changed in a future version, please log your request into MSCONNECT:
These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.
Duilio Tacconi (dtacconi)
Microsoft Dynamics Italy
Microsoft Customer Service and Support (CSS) EMEA
Microsoft Office has a very interesting feature called Click-to-Run. It is a new software delivery mechanism. Office Click-to-Run is optimized for home users on broadband connections. Programs delivered via Click-to-Run execute in a virtual application environment on your computer. This means that the programs have private copies of their files and settings, and that any changes they make are captured in the virtual environment. You can read more about Click-to-Run here. Office applications like Excel and Word are not directly installed on the computer and rather on a virtual file system not accessible by a Windows user (not even administrator). You can continue to use Excel, Word as you know them but when it comes to Exporting to Office from NAV, we have a problem. NAV cannot seem to locate Excel and throws an error instead "It is not possible to locate the program ‘Microsoft Excel’ on your computer. Contact you system administrator." Why does this happen? Simply because NAV tries to locate Excel in the registry with it's otherwise default install path i.e. C:\Program Files (x86)\Microsoft Office\EXCEL.exe but with Click-to-run this path does not exist since it's managed by CVH.exe (a Virtual Handler) and the target path for Excel then becomes something like this: "C:\Program Files (x86)\Common Files\microsoft shared\Virtualization Handler\CVH.EXE" "Microsoft Excel 2010 9014006204090000" So how do we fix this?There are a couple of methods but nothing as straight as installing an Office Professional edition. Click-to-run is delivered with Home and Business edition and if you plan on using it with NAV then it's best to avoid the Home and Business edition. Recommended edition of Office for NAV would be Office Professional edition. This is not elaborated on the System requirements but we are pushing for that to happen.You can also instead switch to using an MSI based Office edition using these instructions: http://office.microsoft.com/en-us/excel-help/click-to-run-switch-to-using-an-msi-based-office-edition-HA101850538.aspxMohamad VajidMicrosoft Dynamics NAVEMEA Customer Service & Support - SMS&P
With more and more focus on cloud computing and cloud services, I have been asked several times about the possibility of using Dynamics NAV with SQL Azure. So I decided to write this blog entry to help "shed some light" on the topic.
What is SQL Azure you ask? SQL Azure is the cloud version of Microsoft SQL Server. The difference is that it's a cloud database running in Microsoft datacenters around the globe. High-availability and fault tolerance are built in.
Even though SQL Azure is based on the SQL Server you are all familiar with, there are some important differences that directly affect its ability to be used a database platform for Dynamics NAV that need to be reviewed and considered. In this post I will go over some of the important differences between the two database platforms and their implications for Dynamics NAV.
Differences That Affect NAV
SQL Azure has a 50 gigabyte limit per database. This is because SQL Azure is based on a "scale - out" database "sharding" model where the data for a single application is no longer stored in one monolithic database but broken up over many smaller databases allowing Azure to scale across many "physical" servers for much higher scalability. The issue with this is that Dynamics NAV (or any of the Microsoft ERP products for that matter) is not architected to support database "sharing" as this is a relatively new concept for SQL Server, which for years has followed a "Scale Up" instead of "Scale Out" model. Dynamics NAV's data engine would have to be completely re-architected to be able to support this model. So if your NAV database is over 50 GB or will ever be over 50 GB, using SQL Azure as a database platform for NAV is not currently possible due to its application architecture.
The initial database creation is handled via TSQL scripting or the SQL Azure Portal. The SQL Azure portal will allow you to create new empty database but not restore a database from back-up. Currently in NAV you can create the Cronus database by restoring the provided SQL back-up on the server. You are also able to create a database and do the necessary coding and configuration and then restore it into the production environment. On SQL Azure these two activities are not currently possible. In order to restore the Cronus database or development database into a SQL Azure environment you would need to script the creation of all objects: tables, views, indexes, functions, and so on and also script the importing of data via TSQL, BCP, or SSIS. This can be done and once you get used to it probably would not be much of an issue, but for people not that familiar with TSQL scripting this could present a significant challenge.
When using an on-premise SQL Server, you can set collations at server, database, column, and expression levels. SQL Azure does not allow setting the collation at the server or database level. To use the non-default collation with SQL Azure you need to set the collation at the column level or the expression level. This could pose a major issue for Dynamics NAV installs not using code page 1252.
SQL Azure does not support tables without clustered indexes. A table must have a clustered index. If a table is created without a clustered constraint, a clustered index must be created before an insert operation is allowed on the table. This is not a big issue as the standard NAV database has clustered indexes on all tables, but could be an issue for people who use staging tables in Dynamics NAV for data migrated from other data sources as these types of tables perform better without a clustered index.
Note: Currently Dynamics NAV does not support SQL Azure, but we are evaluating it for possible future use.
Michael De Voe
Senior Premier Field Engineer
Microsoft Certified Master - SQL Server 2008
I have recently come across an issue with a large Dynamics NAV customer where queries that normally ran VERY quickly became slower and slower over time and blocking was increased significantly. After going through the normal troubleshooting activities there seemed to be no easily explainable cause for the degraded performance. Essentially we were seeing queries that normally should take just a handful of milliseconds were suddenly taking hundreds of milliseconds to complete, causing increased blocking and degraded performance across the board.
After doing some research on the issue we came across a potential cause for the degraded performance. The potential cause was a rather obscure issue (obscure in the fact that it is something I have not seen it cause issues with NAV in the past). The issue has to do with the SQL Server TokenAndPermUserStore growing significantly over time which causes increased query times across the board, which leads to increased blocking and generally poor performance and a degraded end user experience. In summary, the TokenAndPermUserStore is a security cache that maintains the following security token types; LoginToken, TokenPerm, UserToken, SecContextToken, and TokenAccessResult. When the cache store grows, the time to search for existing security entries to reuse increases, causing slower query times. Access to this cache is controlled so that only one thread can perform the search. This behavior eventually causes query performance to decrease, and more CPU utilization occurs.
Some Symptoms of TokenAndPermUserStore Issue:
*You can use the following query to check the size of the TokenAndPermUserStore
SELECT SUM(single_pages_kb + multi_pages_kb) AS "CurrentSizeOfTokenCache(kb)"
FROM sys.dm_os_memory_clerks WHERE name = 'TokenAndPermUserStore'
**In SQL Server 2008 R2 there is a bug that when you run DBCC FREESYSTEMCACHE to clear the TokenAndPermUserStore it does not work. There is a fix for this included in cumulative update package 3 for SQL 2008 R2. The latest update package for R2 is CU 4.
In the case of this customer the TokenAndPermUserStore had grown to 6.8GB. Normally, this should not grow to more than a few hundred Megabytes and even at that level could potentially cause issues depending on how much memory SQL Server has available.
An easy way to test whether this issue is causing a performance problem is to run the following query to clear the TokenAndPermUserStore and if performance improves it is likely that this was the cause or one of the causes of your performance issues.
DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')
There are two potential fixes/workarounds.
More information about the TokenAndPermUserStore
-Michael De Voe
In this blog you will find attached a very simple usage of .NET interoperability with Dynamics NAV 2009 R2 with the objective of basic file management (move, copy, open, delete) WITHOUT using the FILE virtual table and is intended just to familiarize with this brand new feature proposed with NAV 2009 R2 release.
File management is made at client side (RoleTailored client side).
If you want to know more about .NET interoperability for NAV 2009 R2, please refer to MSDN link:
Extending Microsoft Dynamics NAV Using Microsoft .NET Framework Interoperability
.NET interoperability (variables) are generally based on the System.IO namespace:
What you will find in the TXT file:
What to do to let it work (initial setup):
1. Populate the Client Files Management Setup table 50300 with the appropriate values :
2. Once you have completed setup as per point 1, now you are really ready to manage files using the RTC and simply run Page 50200 Client Files Management.
Action buttons Legend:
Move Back - Move Forward
These are enabled since the beginning and permit the user to browse up and down the Directories hierarchy.
OPEN File - DELETE File
Once you have selected your source file (From File), these buttons will be shown. They permit the user to Open (a simple HYPERLINK) or delete the file selected. If the To file is selected (the "Done" option in the To File is selected) these actions refer to the To File. (Obviously you can change this how you wish, since you have the code under your fingers).
COPY File - MOVE File
These are the clue actions. They are enabled once the user has selected both the source file (From File) and the destination file (To File) and checked the 2 "Done" Options for "Manage File" and "Into File" groups (as reported in the first screenshot).
Solution developers will often have different versions of Dynamics NAV installed on a single machine for their development environment. The way this is often implemented is to fully install the latest version and simply copy the Classic Client binary files for earlier versions into separate folders so you have something like this:
NAV 2009 R2 fully installed with an R2 SQL Server database C:\NAVCLIENTS\NAV 40 SP3\ClassicClient (containing NAV binary files. A NAV 4.0 SP3 database is also accessible on the machine) C:\NAVCLIENTS\NAV 50 SP1\ClassicClient (similar setup to above) C:\NAVCLIENTS\NAV 2009\ClassicClient C:\NAVCLIENTS\NAV 2009 SP1\ClassicClient
This approach has been working for solution developers for some time now. However, after installing Dynamics NAV 2009 R2, if you then try to view the Layout for an NAV 2009 SP1 Report you will get the following error:
--------------------------- Microsoft Dynamics NAV Classic --------------------------- It is not possible to instantiate the Visual Studio bridge. --------------------------- OK ---------------------------
This is due to a design change in NAV 2009 R2 which uses the .NetBridge rather than the old Visual Studio bridge component. However, the Visual Studio bridge files are included with the binaries in the NAV 2009 SP1 Classic Client folder so you can avoid the above error by running REGASM.EXE to register the DLL. The REGASM.EXE is included in the .Net Framework folder so executing the following command from within the NAV 2009 SP1 Classic Client folder should do the trick:
Of course, the REGASM.EXE may be located in a different path in your machine so alter the above command line as required.
Gerard Conroy Microsoft Dynamics NAV Support
In Microsoft Dynamics NAV 2009 R2 we have new feature named "Defining the Time Zone for Web Services". You can read about it at http://msdn.microsoft.com/en-us/library/gg502505.aspx . The same feature exists in Microsoft Dynamics NAV 2009 SP1 since build 31926 with KB 2443436. However we have few support requests when NAV developers or users don't know about this feature availability or don't know how to use it.I will try to describe in samples what results we have with different sets.
This feature is important only when you are using date; time or datetime fields and functions to create it. So I created table which has date; time; datetime and description fields
I created codeunit which will be published to Web Service and we'll call function cr_dateTime to create date = Jan 10th 2011Time = 3:00:00 PMAnd DateTime from these values.
In Visual Studio I created C# application which just runs function from codeunit.
WSDT is reference to my Web Service codeunit
And now came main feature point: In CustomSettings.config file could be added new key: "WebServiceDefaultTimeZone".Actually there could be few possibilities:1. Key doesn't exists. Then WS works as before this feature implementation - WS uses UTC time zone2. Key value is empty. The same as point 1 - uses UTC time zone3. Key value is "UTC". This is default value in Dynamics NAV 2009 R2. WS uses UTC time zone.4. Key value is "Server Time Zone". WS will work using server computer default time zone. If you are using any time/date functions in code then this key will get you the same results as code running on Classic Client; RTC or NAS.5. Use any other value from available time zones constants. You can find it at Microsoft Time Zone Index Values at http://support.microsoft.com/kb/973627 . Actually these values already must be in windows registry and if it doesn't exists there, you will have error during WS start.
Here are few of possible time zones values.
My local time zone is "FLE Standard Time"-GMT+02:00, and we need to remember this during execution. So I'm running function from codeunit using different sets.
So it looks everything clear now. However there are few more points need to be mentioned.In my samples I created datetime using function CREATEDATETIME(011011D,150000T); But what will happen if I will use function CREATEDATETIME(TODAY,TIME);? Problem is that TIME function also knows about time zones and will use it during calculation.Look, here is example using different "WebServiceDefaultTimeZone" values, and I set to t_time value from TIME and to d_date value from TODAY. When I did tests it was 11th of Jan 2011 about 10:15 AM morning.
You see differences?
1st entry is by direct codeunit run - my correct time.2nd entry without key and here comes UTC time.3rd entry with "Server Time Zone" - my correct time4th entry with "Standard Central Time" (GMT-06:00) - correct time in that zone (10:21-2:00-6:00).
But look to date_time field - it shows correct time for my zone even everything is different. Why?
It is because datetime uses UTC - look what SQL shows.1st row - my local time 10:15 - 2:00(my time zone) = 08:15 UTC.2nd row - UTC time now is 08:18 and the same is in datetime.3rd row - the same as in 1st row4th row - local time in that time zone is 2:21 AM; UTC time is 8:21 AM and this is in SQL.
I hope this is clear.At least you can play with some samples and you will find the way you need to have as result.
Best RegardsGedas BusniauskasMicrosoft LithuaniaMicrosoft Customer Service and Support (CSS) EMEA
With Microsoft Dynamics NAV 2009 R2, you can configure Microsoft Dynamics NAV Server to specify the time zone in which web services calls are run. You do this by configuring the WebServicesDefaultTimeZone setting in CustomSettings.config file, the Microsoft Dynamics NAV Server configuration file.
The following table describes the possible values for the WebServicesDefaultTimeZone setting.
Specifies any Windows time zone as defined in the system registry on the computer running Microsoft Dynamics NAV Server, under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones. For example, if you want all web service calls to be run in the time zone for Tbilisi, Georgia, you would configure this setting with this value:
<add key="WebServicesDefaultTimeZone" value="Caucasus Standard Time"/>
One flaw has been found with this new setting. The default value for WebServicesDefaultTimeZone is UTC. However, some versions of Windows do not contain a UTC value in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones subkey in the registry. If there is no UTC value in the registry, the Microsoft Dynamics NAV Server and Microsoft Dynamics NAV Business Web Services services cannot start when the WebServicesDefaultTimeZone setting is set to UTC.
One way to remedy this problem is by setting WebServicesDefaultTimeZone to a null string, which causes all business logic for web services to run in UTC. Another way is just to set the parameter to another valid value, as in the example above.