kolovoz 2009 - Posts - DamirDobric

Authentication Problems by using of NTLM

When configuring NTLM in an enterprise you may get error message like this one:
”Authentication error HTTP 401” (sometimes 401.1). Depending on the client you use this error can be shown for example in the browser if you try to access some page on some site which is hosted at your web server. For example the web site could be Share Point or some custom web application.
More over this error can also occur by trying to access the web service hosted in IIS.

If you take a look in the security event log following error event can be found:

Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 537
Date: Date
Time: Time
User: NT AUTHORITY\SYSTEM
Computer: Computer_Name
Description: Logon Failure:
Reason: An error occurred during logon
User Name: User_Name
Domain: Domain_Name
Logon Type: 3
Logon Process: Ðùº
Authentication Package: NTLM
Workstation Name: Computer_Name
Status code: 0xC000006D
Substatus code: 0x0
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: IP_Address
Source Port: Port_Number

If you use Service Trace Viewer this error will appear:

The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'.

As you see the service expect NTLM, the client sends NTLM and the request will be rejected.

This happens when you try to access a server (web app, web service etc.) locally by using its fully qualified domain name (FQDN) or its CNAME alias in the following Universal Naming Convention (UNC) path. When you try to access the service from some other machine all should work fine if your application does not invoke some other service which is possibly physically hosted at the same machine.

Calls that are made from a Web service to other service do not result in this case in an HTTP 401 message in the IIS logs. An HTTP 401 message may be (but not always) noted in the Description section of an Error event for an application that uses a Web service. In this case the calling service will write the error in the trace file if activated at all.

What is the issue?

Windows Server 2003 SP1 introduced a concept of loopback security check. This feature is also present in Windows Server 2008 and was present since in XP SP2. The feature prevents access to a web application using a fully qualified domain name (FQDN) if an attempt to access it takes place from a machine that hosts that application.
|
Unfortunately error code 401.1 is not helpful as this error code means there is a problem with the user credentials.

Fix

Method 1: Specify host names

Note We recommend that you use this method.
To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

In Registry Editor, locate and then click the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

Examples: www.daenet.eu, currencyserver.de

Method 2: Disable the loopback check

Follow these steps:

In Registry Editor, locate and then click the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

In the Value data box, type 1, and then click OK.

Do not forget to restart machine!

In Context of WCF

This problem can easily be worked around even without fixes shown above. All you have to do is to add the default host header to the application. The problem is when you host more applications on one box. In this case you cannot share default host header across multiple applications.

Additionally by using of WCF web services it is not allowed to define two host headers for one service. This would implicitly cause service host to create two endpoints on the same scheme (http) and the service will fail on start up.

Posted kol 28 2009, 02:30 by anonymous

SOAP Faults and New Network Stack in Silverlight 3

Receiving SOAP faults is not supported in the default configuration. This seems to be some Web browser limitation, but a nightmare for WCF developer.
When one service sends a fault message, an exception is thrown on the client. Unfortunately it does not specify any information about the fault that has occurred. Fortunately in SL3, there are two ways to enable SOAP fault consumption. This makes you feel good at least, because you probably think there are two possible solutions now. I will describe both in this post, but in my opinion no one is the the ultimate one (see conclusion below).

Using of Browser Network Stack

If you modify your service to return SOAP faults with an HTTP status code of 200, Silverlight 3 will successfully process faults. Note that this will make the service non-compliant with the SOAP protocol, since SOAP requires a response code in the 400 or 500 range for faults. If the service is a WCF service, you can create an endpoint behavior that plugs in a message inspector that changes the status code to 200. Then, you can create an endpoint specifically for Silverlight consumption, and apply the behavior there. Your other endpoints can remain SOAP-compliant.

For example, usually when service throws an FaultException the client will experience the Communication Exception as shown at the next picture:

Exactly this is the problem, because you will get an error like “Not found” for every possible fault exception thrown by the service. In Other words you will not be able to implement error handling.

To workaround this following WCF Behavior can help. To make it working do following.

1. Download the bits and copy the DLL Daenet.SLFaultCorrector.Dll in the bin folder of your service.
2. Create service configuration as shown at the next picture. Note that the configuration for service registers custom endpoint, defines an extra endpoint for Silverlight applications and related endpoint behavior, which will register an internal inspector for handling of faults.
Here is the configuration which contains all:

<system.serviceModel>
    <extensions>
      <behaviorExtensions>
        <add name="silverlightFaultCorrector"
             type="Daenet.SLFaultCorrector.SLFaultCorrector, Daenet.SLFaultCorrector,
                   Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
      </behaviorExtensions>
    </extensions>

    <services>
      <service name="Daenet.SecurityManager.Service.SecurityManagerService"
               behaviorConfiguration="Daenet.SecurityManager.AdministrationService.AdminServiceBehavior">

       <!- Endpoint for Standard SOAP clients -->
        <endpoint address="" binding="basicHttpBinding"
                  contract="Daenet.SecurityManager.Service.ISecurityManagerService"
                  bindingConfiguration="SecMgrAdminService_IAdminService">
        </endpoint>

       <!- Endpoint for Silverlight clients –>
        <endpoint address="SilverlightEndpoint" binding="basicHttpBinding"
                behaviorConfiguration="SilverlightFaultBehavior"
                contract="Daenet.SecurityManager.Service.ISecurityManagerService"
                bindingConfiguration="SecMgrAdminService_IAdminService"/>

      </service>
    </services>
    <bindings>
      <basicHttpBinding>
        <binding name="SecMgrAdminService_IAdminService"
                 maxBufferSize="2147483647"
                 maxReceivedMessageSize="2147483647">
          <security mode="TransportCredentialOnly">
            <transport clientCredentialType="Windows" />
          </security>
        </binding>
      </basicHttpBinding>
    </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior name="Daenet.SecurityManager.AdministrationService.AdminServiceBehavior">
          <serviceMetadata httpGetEnabled="True" />
          <serviceDebug includeExceptionDetailInFaults="true" />
          <serviceThrottling maxConcurrentCalls="32" maxConcurrentSessions="1000" maxConcurrentInstances="32" />
        </behavior>

      </serviceBehaviors>

      <endpointBehaviors>
       <!- Behavior which is used by Silverlight clients only-->
        <behavior name="SilverlightFaultBehavior">
          <silverlightFaultCorrector/>
        </behavior>
      </endpointBehaviors>

    </behaviors>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="false" />
</system.serviceModel>

As you see I have used two different endpoints above. One can be used by common SOAP capable clients. The second one should be used by Silverlight clients. If the first endpoint can be accessed by following URI http://localhost/SecurityManagerService/SecurityManagerService.svc, then the extra Silverlight endpoint would have this URI http://localhost/SecurityManagerService/SecurityManagerService.svc/SilverlightEndpoint. This works fine for IIS too.

Now your are done with the service. However extracting of one fault exception at the client side in SIlverlight is also a little issue. Following code snippet shows how to grab the service thrown fault in a case of Daenet.SLFaultCorrector":

FaultException fault = e.Error as FaultException;

if (fault != null)
{
if (fault.CreateMessageFault().GetDetail<SecurityManagerFault>() is SecurityManagerFault)
{
    // Handle your fault exception here. In this case SecurityManagerFault.

}
else
{
     // Handle none fault exceptions here
}
}

The catched exception looks now a bit different than in the previous case:

One more thin at the end of this story. To be able to use typed fault exceptions the operation contract has to be styled for this purpose:

[OperationContract]
[FaultContract(typeof(SecurityManagerFault))]
void MyOperation( . . . );

Using of alternative Http Stack (ClientHttp since Silverlight 3)

Additionally since SL3 You can register an alternative HTTP stack using the RegisterPrefix method. Following line of code should be executed at the very beginning of the application to setup the new stack.

bool registerResult = WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);

Silverlight 3 provides the “client HTTP stack” which, unlike the “browser HTTP stack”, allows you to process SOAP-compliant fault messages. However, a potential problem of switching to the alternative HTTP stack is that information stored by the browser (such as authentication cookies) will no longer be available to Silverlight, and thus certain scenarios involving secure services might stop working, or require additional code to work. For more information, see HttpCookieContainerBindingElement.
I figured out that windows authentication which has been used in my services does not work anymore by using of new network stack. By default service proxies at the client do not send required authentication headers.

Conclusion:

If you use first method (the old one) you have to force your service to be incompatible with SOAP protocol (Additional endpoints are required). If you use the second method you will not be able to authenticate by using of NTLM or Kerberos.

Posted kol 22 2009, 12:17 by anonymous

Configuring and Troubleshooting NTLM and Kerberos on Windows 7 (Windows Server 2008) and IIS7

Sometimes it might be required to enable NTLM in IIS. One good reason for this could be some service suite (for example bunch of WCF service). As long you enable your services internally in your enterprise you should enable KERBEROS authentication only. This kind of authentication is internally in IIS called Windows Authentication or Windows Integrated Authentication. However in this context there are two different kind of Windows Integrated Authentication:

- Negotiate (or kerberos)
- Ntlm (or chalenge response)

Which kind of authentication will be used it is defined by target site. One site (application) can require NTLM, Negotiate or both. When some site requires NTLM and Kerberos (Negotiate)authentication following response would be returned by the site, when some client sends requests:

HTTP: Response, HTTP/1.1, Status Code = 401
ProtocolVersion: HTTP/1.1
StatusCode: 401, Unauthorized
Reason: Unauthorized
ContentLength: 1656
ContentType: text/html
Server: Microsoft-IIS/6.0
WWWAuthenticate: Negotiate
WWWAuthenticate: NTLM

If one authentication would be allowed (required), then one of last two self explaining entries in the response would appear in response. Fore more information about proticols teke a look here. To enable Windows Integrated Authentication authentication type in IIS7 start Internet Information Server Manager (simply start inetmgr.exe), select the wanted site or application and open authentication features.

If Windows Integrated Authentication is installed you will see following.

Here you can enable and disable it. If the wanted authentication type does not appear in the list you can install it by turning of windows features on.

After all you can set the required authentication mechanism on NTLM or Negotiate as shown at the next picture:

After that you can set the priority of providers. Next picture shows that KERBEROS is the preferred one. That means, if for example the browser can talk both protocols the kerberos will be used.

This was the simple and nice part of the story, because real troubles start just now. If you are very lucky, you are done now. According to morphs low, you are now on the beginning.
First problem you will get with KERBEROS when clients should access the site (service) by using of some specific alias like: http://myservice.testdomain.com. However your IIS host machine would be internally accessible as http://yourhost.testdomain.com. (yourhost is the hostname of the machine which host the IIS, which will host the service.)

If the client cannot authenticate, because of KERBEROS do following:

c:\>setspn -L yourhost

This command will list registered SPN-s:

Registered ServicePrincipalNames for CN=YOURHOST,CN=Computers,DC=TESTDOMAIN,DC=COM:
         MSSQLSvc/YOURHOST.TESTDOMAIN.COM:MSSQLSERVER2008
        RestrictedKrbHost/DADO-NB0
        HOST/YOURHOST
        RestrictedKrbHost/YOURHOST.TESTDOMAIN.COM
        HOST/YOURHOST.TESTDOMAIN.COM

This is default configuration which will not work. To enable KERBEROS to authenticate aganist external qualified name like myservice.testdomain.com do following:

c:\>setspn -A HTTP/myservice.testdomain.com YOURHOST

Optionally, you can define more qualified names:

c:\>setspn -A HTTP/myservice YOURHOST

To be sure that all is done, enlist registered SPNS-s again:

c:\>setspn -L yourhost

This should be the result now:

Registered ServicePrincipalNames for CN=YOURHOST,CN=Computers,DC=TESTDOMAIN,DC=COM:
HTTP/myservice.testdomain.com
HTTP:/myservice
MSSQLSvc/YOURHOST.TESTDOMAIN.COM:MSSQLSERVER2008
RestrictedKrbHost/DADO-NB0
HOST/YOURHOST
RestrictedKrbHost/YOURHOST.TESTDOMAIN.COM
HOST/YOURHOST.TESTDOMAIN.COM

After that restart your machine and pray. I mean this seriously, because changes will not take effect immediately even after restart. Sometimes I was even giving up, and then after few hours it just worked.

SPN-s in Win 7 and Win Server 2008 R2

In Windows 7 and Windows Server 2008 R2 some things might be slightly different.Two new types of service accounts are available in Windows Server® 2008 R2 and Windows 7. The managed service account and the virtual account. The managed service account is designed to provide crucial applications such as SQL Server and IIS with the isolation of their own domain accounts, while eliminating the need for an administrator to manually administer the service principal name (SPN) and credentials for these accounts. Virtual accounts in Windows Server 2008 R2 and Windows 7 are "managed local accounts" that can use a computer's credentials to access network resources. Unlike with normal local computer and user accounts, the administrator does not have to complete complex SPN management tasks to use managed service accounts.

If you have survived SPN-step you could be done. But, if you develop internet applications like Silverlight or ASP.NET, which should invoke operations on your service, KERBEROS (Negotiate) cannot be used. The reason is that KERBEROS is not really internet capable protocol, because KERBEROS required ports are by default blocked by firewalls out of your enterprise.

In this case your authentication adventure is not completed yet. As next, you should enable NTLM protocol. This one is not that safe as Kerberos, but it can be used in internet as long browsers supports it (for example IE and Firefox).

Usually, NTLM doesn’t make so much troubles like Kerberos. Unfortunately, if it does, it could be much, much more complicated than Kerberos. I have experienced two possible issues with NTLM: DNS configuration and using of Windows 7 (or Win Server 2008 R2)

NTLM Dns Configuration issue

I figured out that if myservice entry in DNS server is of host type and the machine which host IIS does not have the same name (in our example it has the name: yourhost) the authentication will fail with code: 401.1. Usually you will not find any more detailed information about the reason, why this has happened. I was digging in event logs, IIS logs etc, and didn’t find anything.
The solutions is more than simple. Just reconfigure DNS entry myservice to be an alias which points to yourhost. After that all will work immediately, if you are not lucky user of Windows 7 or Windows Server 2008 R2.

Posted kol 16 2009, 08:06 by anonymous

Enabling of NTLM on Windows 7 and Windows Server 2008 R2

New operative systems are by default not very friendly to NTLM authentication. The introduce a set of group policies which control who can use NTLM in enterprise. Following picture shows the final configuration which I set up at my development machine:

First of all I would recommend you enable auditing. This will give you enough information about hidden NTLM details. After you have configure them you can use NTLM event log for diagnostics:

Network security: Restrict NTLM: Audit Incoming NTLM Traffic

This policy setting allows you to audit incoming NTLM traffic.

If you select "Disable", or do not configure this policy setting, the server will not log events for incoming NTLM traffic.

If you select "Enable auditing for domain accounts", the server will log events for NTLM pass-through authentication requests that would be blocked when the "Network Security: Restrict NTLM: Incoming NTLM traffic" policy setting is set to the "Deny all domain accounts" option.

If you select "Enable auditing for all accounts", the server will log events for all NTLM authentication requests that would be blocked when the "Network Security: Restrict NTLM: Incoming NTLM traffic" policy setting is set to the "Deny all accounts" option.

This policy is supported on at least Windows 7 or Windows Server 2008 R2.

Note: Audit events are recorded on this computer in the "Operational" Log located under the Applications and Services Log/Microsoft/Windows/NTLM.

Network security: Restrict NTLM: Audit Incoming NTLM Traffic

This policy setting allows you to audit incoming NTLM traffic.

If you select "Disable", or do not configure this policy setting, the server will not log events for incoming NTLM traffic.

If you select "Enable auditing for domain accounts", the server will log events for NTLM pass-through authentication requests that would be blocked when the "Network Security: Restrict NTLM: Incoming NTLM traffic" policy setting is set to the "Deny all domain accounts" option.

If you select "Enable auditing for all accounts", the server will log events for all NTLM authentication requests that would be blocked when the "Network Security: Restrict NTLM: Incoming NTLM traffic" policy setting is set to the "Deny all accounts" option.

This policy is supported on at least Windows 7 or Windows Server 2008 R2.

Note: Audit events are recorded on this computer in the "Operational" Log located under the Applications and Services Log/Microsoft/Windows/NTLM.

Additionally to auditing policies there are few other restricting policies:

Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication

This policy setting allows you to create an exception list of remote servers to which clients are allowed to use NTLM authentication if the "Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers" policy setting is configured.

If you configure this policy setting, you can define a list of remote servers to which clients are allowed to use NTLM authentication.

If you do not configure this policy setting, no exceptions will be applied.

The naming format for servers on this exception list is the fully qualified domain name (FQDN) or NetBIOS server name used by the application, listed one per line. To ensure exceptions the name used by all applications needs to be in the list, and to ensure an exception is accurate, the server name should be listed in both naming formats . A single asterisk (*) can be used anywhere in the string as a wildcard character.

Network security: Restrict NTLM: Audit NTLM authentication in this domain

This policy setting allows you to audit NTLM authentication in a domain from this domain controller.

If you select "Disable" or do not configure this policy setting, the domain controller will not log events for NTLM authentication in this domain.

If you select "Enable for domain accounts to domain servers," the domain controller will log events for NTLM authentication logon attempts for domain accounts to domain servers when NTLM authentication would be denied because "Deny for domain accounts to domain servers" is selected in the "Network security: Restrict NTLM: NTLM authentication in this domain" policy setting.

If you select "Enable for domain accounts," the domain controller will log events for NTLM authentication logon attempts that use domain accounts when NTLM authentication would be denied because "Deny for domain accounts" is selected in the "Network security: Restrict NTLM: NTLM authentication in this domain" policy setting.

If you select "Enable for domain servers" the domain controller will log events for NTLM authentication requests to all servers in the domain when NTLM authentication would be denied because "Deny for domain servers" is selected in the "Network security: Restrict NTLM: NTLM authentication in this domain" policy setting.

If you select "Enable all" the domain controller will log events for NTLM pass-through authentication requests from its servers and for its accounts which would be denied because "Deny all" is selected in the "Network security: Restrict NTLM: NTLM authentication in this domain" policy setting.

This policy is supported on at least Windows Server 2008 R2.

Note: Audit events are recorded on this computer in the "Operational" Log located under the Applications and Services Log/Microsoft/Windows/NTLM.

Network security: Restrict NTLM: Incoming NTLM traffic

This policy setting allows you to deny or allow incoming NTLM traffic.

If you select "Allow all" or do not configure this policy setting, the server will allow all NTLM authentication requests.

If you select "Deny all domain accounts," the server will deny NTLM authentication requests for domain logon and display an NTLM blocked error, but allow local account logon.

If you select "Deny all accounts," the server will deny NTLM authentication requests from incoming traffic and display an NTLM blocked error.

This policy is supported on at least Windows 7 or Windows Server 2008 R2.

Note: Block events are recorded on this computer in the "Operational" Log located under the Applications and Services Log/Microsoft/Windows/NTLM.

Network security: Restrict NTLM: NTLM authentication in this domain

This policy setting allows you to deny or allow NTLM authentication within a domain from this domain controller. This policy does not affect interactive logon to this domain controller.

If you select "Disabled" or do not configure this policy setting, the domain controller will allow all NTLM pass-through authentication requests within the domain.

If you select "Deny for domain accounts to domain servers" the domain controller will deny all NTLM authentication logon attempts to all servers in the domain that are using domain accounts and return an NTLM blocked error unless the server name is on the exception list in the "Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain" policy setting.

If you select "Deny for domain account" the domain controller will deny all NTLM authentication logon attempts from domain accounts and return an NTLM blocked error unless the server name is on the exception list in the "Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain" policy setting.

If you select "Deny for domain servers" the domain controller will deny NTLM authentication requests to all servers in the domain and return an NTLM blocked error unless the server name is on the exception list in the "Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain" policy setting.

If you select "Deny all," the domain controller will deny all NTLM pass-through authentication requests from its servers and for its accounts and return an NTLM blocked error unless the server name is on the exception list in the "Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain" policy setting.

This policy is supported on at least Windows Server 2008 R2.

Note: Block events are recorded on this computer in the "Operational" Log located under the Applications and Services Log/Microsoft/Windows/NTLM.

Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers

This policy setting allows you to deny or audit outgoing NTLM traffic from this Windows 7 or this Windows Server 2008 R2 computer to any Windows remote server.

If you select "Allow all" or do not configure this policy setting, the client computer can authenticate identities to a remote server by using NTLM authentication.

If you select "Audit all," the client computer logs an event for each NTLM authentication request to a remote server. This allows you to identify those servers receiving NTLM authentication requests from the client computer.

If you select "Deny all," the client computer cannot authenticate identities to a remote server by using NTLM authentication. You can use the "Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication" policy setting to define a list of remote servers to which clients are allowed to use NTLM authentication.

This policy is supported on at least Windows 7 or Windows Server 2008 R2.

Note: Audit and block events are recorded on this computer in the "Operational" Log located under the Applications and Services Log/Microsoft/Windows/NTLM.

Posted kol 16 2009, 08:04 by anonymous

Filed under: WCF

Building Custom Virtual Earth

For all of you who need or ever wanted to build you own virtual earth map, here is an example which shows how to do this.
Note that Virtual Map Images are hosted at http://daenet.eu/share/maps. Please note that these are just for demo purposes and should not be used by anybody.
daenet does not guarantee that maps will remain at this location.

If you want to know more about how to build your own maps, we recommend following description at bing-official site. We have build maps by using of MapCruncher tool.

At following link you can see the sample in action.

Posted kol 07 2009, 02:35 by anonymous

DropShadowEffect causes performance degradation in Silverlight

When working with Silverlight you might notice sometimes performance degradation which you cannot explain. To ilustrate this take a look on following XAML example.

The picture above shows one page in XAML which contains two commented blocks. When these blocks are included in rendering process you will notice
very bad rendering performance. When these to effects are excluded from code you will reach much higher rendering performance.

Silverlight shader effects in general are rendered in software mode. Any object that applies an effect will also be rendered in software mode. Performance is degraded the most when using effects on large visuals or animating properties of an effect. This is not to say that you should not use shader effects in this way at all, but you should use caution and test thoroughly to ensure that your users are getting the experience you expect.

When you work with designers please be sure that people are aware of this.

Posted kol 07 2009, 01:50 by anonymous

Silverlight3 Breaking Change

If you have developed SIlverlight < 3.0 apps, you might (sometimes) notice that some of them will not work on Silverlight 3.0
One of issues which causes this problem is the fact the Microsoft has decided to remove Silverlight.Dll from Silverlight SDK. This DLL has been build as a helper assembly for ASP.NET with support for dynamic adding of Silverlight and Media controls to the page.

In other words, following is no more supported in SL3:

<asp:silverlight ../>
<asp:mediaplayer ../>

Existing Silverlight applications will continue to have the System.Web.Silverlight assembly in their Web application’s BIN folder, even if the Silverlight 2 SDK is uninstalled. Therefore upgrading to Silverlight 3 SDK will not remove this local assembly and applications should continue to work.

If you want you could reference the System.Web.Silverlight assembly manually and use required controls. However, these controls will not provide the latest installation logic, or be able to render iframes for Silverlight history support.

Following example shows how to add Silverlight control in SL3:

<div id="silverlightControlHost">
    <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%">
     <param name="source" value="{XAP_FILE}"/>
         <param name="onerror" value="onSilverlightError" />
         <param name="background" value="white" />
         <param name="minRuntimeVersion" value="{BUILD}" />
          <param name="autoUpgrade" value="true" />
          <a href="http://go.microsoft.com/fwlink/?LinkID=149156&v={BUILD}" style="text-decoration: none;">
               <img src="http://go.microsoft.com/fwlink/?LinkId=108181" alt="Get Microsoft Silverlight" style="border-style: none"/>
           </a>
       </object>
        <iframe id="_sl_historyFrame" style='visibility:hidden;height:0;width:0;border:0px'></iframe>
</div>

Posted kol 06 2009, 12:53 by anonymous

New BizTalk Server SKU-s

Few days ago at WPC Microsoft has announced new BizTalk Server editions (SKU-s)

BizTalk Server 2009 Enterprise Runtime Edition: Every application needs to integrate with other applications in customer environments and solution companies do not want to reengineer and build an integration server from scratch. BizTalk Server 2009 Enterprise Runtime edition provides all integration capabilities with high availability features and all the adapters to systems like SAP, Oracle E-Business Suite and Mainframe systems. Enterprise Runtime is a special edition for partners designed to be used in support of their ISV application, as part of a unified solution. BizTalk Server 2009 Enterprise Runtime includes all capabilities, adapters and accelerations and supports scale out/failover, multi-server configuration with multiple message boxes.

BizTalk Server 2009 Standard Runtime Edition: BizTalk Server 2009 Standard Runtime Edition is a great option for partners who need low cost option and do not need high availability. Standard Runtime includes all the capabilities of BizTalk Server along with all adapters to embed inside ISV application. Standard Runtime allows partners to deliver 1 BizTalk application and connect to 1 external application. Goal of Standard Runtime is to provide integration capability at a very low price for ISV partners.

BizTalk Server 2009 RFID Edition: RFID is being used to transform business processes by companies across industry verticals. Microsoft first delivered RFID platform as part of BizTalk Server 2006 R2. Now in its 6^th version, BizTalk Server 2009 has made major enhancements to this platform including application platform for mobile RFID devices and support for industry standards like EPCIS, LLRP, and TDT/TDS. Microsoft also received EPCIS certification from GS1 EPCGlobal for BizTalk Server 2009. BizTalk RFID 2009 is a dedicated SKU for partners and customers interested in RFID deployments. It provides capabilities like high availability, plug and play devices; enterprise manageability with System center and SDK for partners and customers to build RFID enabled solutions etc.

Posted kol 05 2009, 10:21 by anonymous

Cannot enable networking for Device Emulator

When developing mobile applications for Windows 7, you may get following error, when trying to enable networking for device emulator:

The required Virtual Machine Network Driver could not be found. Make sure that Virtual PC 2007 is installed. You can install Virtual PC 2007 from http://go.microsoft.com/fwlink/?linkid=46859

This might be frustrating, because you remember that just few days ago all was working fine. The problem is missing networking driver for device emulator called VMNet. This driver is consisted a part of Virtual PC since 2007. Now you can install Virtual PC and all will work fine.
But, hold a moment!? Remember you are running Windows 7 and why you should install Virtual PC 2007 which will not work? This is true. Networking driver will work, but VPC not. Moreover if you have installed Virtual PC for Windows 7 this one will no more work after installing of VP 2007. So, there is no way to make all working, you might think now. The good thing i that there is a way.

Notice that networking driver for emulator is located in VMNetSrv folder of VPC 2007. Make a copy of this folder for the case that installation has to be done manually.
Now, uninstall Virtual PC (if you have install it) reboot the machine (this is important, because driver will continue working even after uninstalling of VPC 2007).
After system restart open networking properties of any adapter, click “install” button, select “services” and then “Virtual Machine Network Services” (see picture below).
If for any reason “Virtual Machine Network Services” does not appear for selection use “browse” button and navigate to VMNetSrv folder which you have previously copied from VPC2007 installation path.

This is where to download VPC 2007: http://go.microsoft.com/fwlink/?linkid=46859

Virtual Machine Network Services (behind VMNet driver) I have been installed was v 26.553.0.

Hope this helps you.

Damir

Posted kol 02 2009, 07:23 by anonymous

Intellectual Error messages

When automating PowerPoint you might get following error:

“COMException: Presentation (unknown member) : An error occurred while PowerPoint was saving the file.”

I have always been asking myself, how to find a optimal path in my brain able to lookup a solution for such errors. Because, the entropy of useful information of this message is nearby zero, it is mathematically almost impossible to solve it. Solving this is equal to finding of solution for some unknown problem.
But, empirically there is a way to narrow the problem. Just, don’t trust the message. Some COM/Office/Errors can mean anything, but not that what you see. :)

This message means, that you are trying to save the file (Presentation.Save or Presentation.SaveCopyAs) to some directory which does not exists.

Posted kol 01 2009, 12:12 by anonymous

Community Blogs

This Blog

Syndication

Recent Posts

Tags

Archives

DamirDobric