How to control your World with Intune MDM, MAM (APP) and Graph API



VSS yedekleme testi nasıl yapılır


Exchange üzerinde bulunan verilerin yedeklenmesi (backup) ve geri yüklenmesi (restore) baslibasina çok önemli bir konudur.  Bir yedegin saglikli alinmasi kadar restore isleminin basarili bir biçimde yapilabilmesi de test edilmesi gereken önemli bir islem. Exchange destegi olan (aware) diye adlandirdigimiz yazilimlar exchange writer'lari kullanarak VSS teknolojisi ile yedek alirlar.

Yedekleme esnasinda karsilasilan sorunlarin büyük bölümünün nedeni, yazilimlarin uyumsuzlugu ya da bu yazilimlardaki yanlis bir ayar olabilmektedir. Bunun tespiti için, yani yedek alma sirasinda sorunun VSS Writer'dan mi, disk sisteminden mi ve/veya yedekleme yazilimindan mi kaynaklandigini anlayabilmek için Betest aracini kullanabilirsiniz.

BETEST, Windows SDK yada Volume Shadow Copy Service SDK 7.2 (sonraki versiyonlarda mevcut) içerisinde bulunan yardimci bir araçtir. Araci kolaylikla bulabilir ve kurabilirsiniz. Kurulum islemini exchange sunucunuza yada herhangi bir windows sunucuya yapmanizi önermeyiz. Bir desktop makinaya kurulum yapildiktan sonra ilgili kütüphaneden BETEST araci test yapilacak ortama tasinip ve test yapilabilir.

Betest ile ilgili hatirlatmak istedigimiz önemli nokta, bu yazilimin sadece test amaçli kullanilmasidir. Bu programi hiçbir zaman normal bir yedekleme yaziliminin ikamesi olarak kullanmayin. DPM gibi bir yedekleme yaziliminiz yoksa Exchange Server yedekleri için Windows Server Backup'i da kullanabilirsiniz 

Betest ile yedekleme yapmak için uygulamaniz gereken adimlar:

Volume Shadow Copy Service SDK 7.2'yi asagidaki web adresinden indirip kurulumunu gerçeklestirin.

           https://www.microsoft.com/downloads/details.aspx?FamilyID=0b4f56e4-0ccc-4626-826a-ed2c4c95c871&displaylang=en

 

Isleme baslamadan önce, Exchange Writer'larinin durumunu kontrol etmek gerekecektir. Bunun için komut satirinda "VSSadmin list writers" komutunu çalistirin. Eger komutu çalistirdiginiz sunucuda sadece aktif durumda veritabani varsa,
Microsoft Exchange Writer'in listelendigini göreceksiniz:

 

Pasif kopya da bulunuyorsa, Microsoft Exchange Replica Writer'da ayrica listelenecektir.

 

Listelenen writerlar ile ilgili özellikle dikkat edilmesi gereken iki bilgi, State ve Last error durumlaridir. Bunlarin sirasiyla Stable ve No error olmalari gerekmektedir.

 

Eger bu writerlardan bir tanesi Failed olmus ise, Information Store ya da Replication Servisini yeniden baslatarak, State'in Stable duruma geçmesini saglayabilirsiniz. Information Store'un yeniden baslatilmasinin kullanicilarin mailbox baglantilarini kesintiye  ugratacagi unutulmamalidir.

Bu adimda, Betest'in yedekleme konfigürasyonunu alacagi Components.txt dosyasini olusturacagiz. Bunun için öncelikle Notepad programini açin.

Components.txt içerisindeki konfigürasyon dosyasinin genel formati asagidaki gibidir. Bunu alacagimiz veritabanina uygun olarak degistirecegiz.

"<WriterId>":
"<component-logical-path>" {"target" # "new
target", ...}, ..."<component-logical-path>" :
'"<subcomponent-logical-path>,...";

WriterId, Vssadmin list writers komutuyla gördügümüz Writer Id'nin karsisindaki guid degeridir.

 

Geri kalan bölümlere ise, yedegi alinacak veritabaninin mantiksal lokasyonu ve GUID'i girilmektedir. Yedegini alacaginiz veritabaninin GUID'ini asagidaki komutla Exchange Management Shell üzerinden ögrenebilirsiniz: 

Get-mailboxdatabase "database--ismi" | fl guid

 

Asagida, aktif bir veritabani için olusturulan Components.txt dosyasi görülmektedir.

 

"{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Mailbox1\a03774fa-434a-49cd-8f99-79d932f5be71";

 

Yukarida, "{76fe..." Writer'in idsi, "mailbox1" sunucunun ismi, "a0377..." veritabaninin GUID numarasidir. Eger veritabani pasif kopya ise, Microsoft Information Store'dan sonar birde Replica eklenmelidir:

 

"{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Replica\Mailbox1\a03774fa-434a-49cd-8f99-79d932f5be71";

 

Yedekleme testini, ayni anda birden fazla veritabani için yapmak isteyebilirsiniz. Bunun içinde, her bir veritabaninin mantiksal path bilgisini, tirnak içerisinde ve virgülle ayirarak eklemeniz gerekmektedir:

 

"{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}": "Microsoft Exchange Server\Microsoft Information Store\Replica\MailboxSunucu\5df67a32-5f44-4585-ad0e-962b70f399d3","Microsoft Exchange Server\Microsoft
Information Store\Replica\MailboxSunucu\35e64d4a-7c6b-41f8-a720-068d2798b908","Microsoft Exchange Server\Microsoft Information Store\Replica\MailboxSunucu\5afe57ab-c14d-4bf9-8a69-78691fad5a33";
 

 Dosya içerigini yukarida belirtildigi sekilde hazirladiktan sonra bunu Components.txt adiyla, C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\amd64 klasörü altina kaydedin.

Komut satirinda betest'in kurulum klasörüne geçin. Betest, varsayilan olarak asagidaki lokasyonda bulunur:

 

 C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\amd64 

Asagidaki komutu çalistirin  

BETEST.exe /B /E /T 1 /S output.XML /C components.txt /D c:\betest > output.txt

Yukarida komutta "c:\betest" yedeklerin olusturulacagi path, output.txt ise yedekleme durumunun görülecegi ve yedekleme islemi bittiginde olusacak olan log dosyasidir. Sariyla isaretlenen lokasyonu
istediginiz gibi degistirebilirsiniz. Asagidaki resimde, Betest tarafindan yedegi alinan veritabani için olusturulmus klasörler görülmektedir.

 

Yedegin alinmasi sirasinda hatayla karsilasilmasi halinde, sorunun Exchange Writer'dan kaynaklandigi söylenebilir.  Islem sonucunda olusan Output.txt dosyasini, inceleme yapilmasi için Microsoft Teknik Destek Merkezine iletebilirsiniz.

Burak Petekkaya


AppStack: Microsoft EcoSystem for Enterprise Web Application Hosting


Before we think about Microsoft Application Hosting component (AppStack), I want to establish my personal preference. Applications nowadays are mixture of UI component and associated web services built in ASP.Net/WCF/WF. My aim is to build application that is Fast, Secure and Resilient and I'll coin the term "FSR" to describe these three attributes.

In order to achieve this goal from application's perspective I prefer applications to be stateless and this extends to servers hosting these applications to be stateless as well. Now there are pros and cons to make application/server stateful and stateless but in long term I would like to think that stateless configuration is more desirable with scalability in mind.

Application Request Routing (ARR): This extension of IIS shows true power of its flexibility by modular architecture. This is very advanced reverse-proxy based solution implemented on top of URLRewrite to increase Web application's scalability and reliability through rule-based routing, client and host name affinity, load balancing of HTTP server requests, and distributed disk caching.

Application Initialization (AppInit): IIS Application Initialization helps to improve responsiveness of web site by loading Web applications before first request arrives. By proactively loading and initializing all dependencies such as database connections, compilation of ASP.NET code, and loading of modules, you can ensure Web sites are responsive at all times even if it uses a custom request pipeline or if Application Pool is recycled or during overlapped recycling.

AppFabric (Caching): This is about making your application fast, scalable and resilient by having distributed memory based cache cluster. AppFabric caching features can help scale your .NET applications easily and inexpensively by allowing you to combine the memory capacity of multiple computers into a single unified cache cluster. These features include Caching Services, Cache Client, and Cache Administration tools. AppFabric Caching Services are highly scalable, allowing many computers to be configured as nodes of a cache cluster that is available as a single unified memory cache. Caching Services provide a high-availability feature that supports continuous availability of your cached data by storing copies of that data on separate cache hosts. When high availability is enabled on a multi-server cluster, your application can still retrieve its cached data if a cache server fails.

AppFabric (Hosting): This is my silver bulletfor effectively manage WCF/WF services on IIS7. AppFabric-Hosting Services includes features provided by Workflow Management Service, including lock/retry, auto-start, durable timers, and a command queue.

  • It provides persistence that works right out of the box. It uses the SQL persistence store that ships with .NET Framework 4, and create a default persistence database that your applications can leverage, which allows you to scale your stateful services across a set of computers.
  • AppFabric Monitoring service allows you to perform health monitoring and troubleshooting of running WCF and WF services, and to control those services.
  • It uses security accounts and SQL Server logins and database roles to determine the access a user or application has to system resources such as persistence databases, timer data, monitoring data, and configuration files. Access to these resources occurs at both application and management levels, which are the two areas of logical scope that relate to the AppFabric security model.
  • To top all that AppFabric Dashboard gives you visibility into the health of a system, and unified configuration user interface gives you control over your service configuration. I cry whenever I see WCF/WF services deployed on IIS without AppFabric!

There are more bells and whistles to add on above list that makes IIS excellent candidate to host your applications but for now it will do. In next post I will describe sample architecture to build web farm using Microsoft WebStack (described in earlier post) and AppStack.


Architecture Diagram: Blueprint for Enterprise Web Infrastructure


In the last two posts we have seen components for Microsoft WebStack and AppStack . In this post I will try put those together to build scalable web farm architecture that will act as our blueprint. Following functional diagram represent the logical view of web farm.

Above diagram represents architecture of two-tier data driven application as described below:

  1. We have two ARR servers to distribute incoming requests to front end servers. These ARR server use memory based and disk based cache for static content. ARR serves are load balanced by either NLB or Hardware load balancer as purely Layer 4 (TCP) load balancer because ARR is acting as Application level load balancer.

  2. Front End servers are stateless server deployed in DMZ responsible for serving ASP.Net pages to clients. These servers don't store any information locally. Session state and any use specific information is stored on AppFabric Caching cluster with local cache enabled.

  3. We have another set of ARR servers to load balance backend service.

  4. Backend servers are responsible for WCF/WF services. These servers are running AppFabric Hosting services, Monitoring and caching client.

  5. We have AppFabric caching cluster for distributed memory cache with fault tolerance enabled to optimize performance and resiliency.

  6. We have SQL Cluster hosting multiple databases needed by Application/ASP.Net and AppFabric. There are three important database for AppFabric:

    1. AppFabric Caching Database to store caching cluster information
    2. Persistence database to persist Workflows
    3. Monitoring Database to store AppFabric Monitoring information.
  7. We have two WFF servers running in Active-Passive mode to manage the WebFarm.

    1. At any given time only Active WFF server is available on network for management and on passive node WebFarm service is disabled. These two servers are configured with Shared-config to synchronize configuration information among them so that in the event of failure of primary node Passive node can be bring online by starting the WebFarm Service.
    2. WFF takes care of adding and removing servers in Web farm. It is configured with two Web farms where servers are grouped together depending upon their role either in FrontEnd or BackEnd webfarm.
    3. One server in each farm is marked as primary server that is not participating in receiving incoming traffic. These servers are used for synchronising application to other servers in farm. (Purely for non-technical (Admin) reasons primary server is not handling active client requests.)
  8. Web applications can be provisioned/updated in two ways:

    1. First and preferred way is via self-service method. Delegations are enabled on application and users are designated as Site/Application administrator. They connect to Primary server remotely in each farm and upload new application. This is the preferred method because of self-service nature of it and no associated administration overhead. WFF will ensure that changes made to primary servers are replicated to other servers in web farm.
    2. Developers can publish a WebDeploy Package from publishing server to central file store. Administrators will create a Platform Provisioning task and as a part of it WebDeploy action will be executed on all servers and application will be provisioned.

Demystifying .Net CLR Perfromance Counter


Hi Friends!!!

I am back in business and apologies for out of contact for a while. Lot of exciting thing happened over past few months. Finally I landed where I always wanted to be so thanks for your support so far and yes your guess is right from the blog addressJ.

I was waiting to right my first post with some exciting information. Exciting means hidden to the world and internet search engines could not find! In my usual style here it goes:

Scenario:

I was at customer site and my task was to monitor the IIS System health and that obliviously means monitoring the application health. I decided to setup performance counter for a start and I opened the Process counter as shown in following figure:

So server was hosting multiple web application and sever had multiple worker processes. In the Instance list all worker process was appearing as w3wp, w3wp#1, w3wp#2 and w3wp#n and so on. Problem was which one is associated with correct application pool?

Resolution:

I executed the following command to get a list of worker processes running on the server and associated process ID.

C:\windows\system32\cscript c:\windows\system32\iisapp.vbs

Output was something like below:

IISApp.vbs 

Then I remembered the one blog post from very dear friend of mine:

https://blogs.technet.com/marcelofartura/archive/2006/09/14/perfmon-s-counters-output-format-tip.aspx

I applied the registry changes as said and voila!!! I got the output as below:

 

Job done! Hum... I am sure you are wondering what is the point of having this blog entry? Such a waste of time isn't it? If you are thinking this than wait...

I opened .Net CLR Counters and specifically .Net CLR Exceptions and .Net CLR Memory and I saw the following:

 

Hum!! Something didn't work as expected. I verified the registry entries and appeared correct to me. I came to conclusion that this registry modifications are not working for .NET CLR counters. Question was how to monitor .Net CLR counters for specific application pool only?

I decided that it is time to call the internal help line and guess what within hours I got reply and reply was amazing that I decided to write this blog.

Guy told me to look for under ".Net CLR Memory" Performance object and asked me "what is the 4th last counter you see?" I was amazed what it has to do with 4th last counter? I looked the counter and it was full of surprise!!! It seemed that "Promoted Finalization Memory from Gen1" is the holly grail!!!! The last value of that counter was actually the worker process ID!! Now you got the relationship between .Net CLR performance counters and Worker process ID as well.

 

Takeaway:

When you have .Net 1.1 installed it loads the .Net 1.1 performance counters and there is no easy way to get this relationship established. However, in .Net 2.0 onwards you can unload the .Net 1.1 counters and reload the .Net 2.0 specific counters with following instructions:

1) Go to \Windows\Microsoft.NET\Framework\v2.0.50727

2) Run "unlodctr .NetFramework"

3) Run "lodctr corperfmonsymbols.ini"

This should load the .Net 2.0 counters from corperfmonsymbols.ini. So what is the difference? Well, see the screenshot below:

 

Now you have the real name of performance counter as well along with real value. Demystifying the secret! Though you have counter listed, it will not work with .Net 1.1.

Well this solution provided as it is and you are at your own risk! Please don't take it as an official supported way to implement and it is kind of working solution. We should expect a lot of improvement on this side with .Net 4.0 so wait and watch!

PS: Special Thanks to Mr. A. Kamath who assisted me with this problem.


How To Migrate SSL Certificate Using MSDeploy


Hi Friends!

Scenario:

Yesterday I was asked to help out IIS 6 to IIS 7 migration with close to 500 sites with 50 of them were SSL website. I thought it is good time to evaluate MSDeploy. It has a support to migrate SSL certificate between the servers and it has really appealed me to use that tool. I opened built in help and I found the following syntax:

msdeploy.exe -verb:sync -source:cert=(STORENAME\HASHOfCERTIFICATE) -dest:cert=(STORENAME\HASHOfCERTIFICATE),computername=DESTINATIONCOMPUTER

I thought that it is something to easy to do. In order to find the SSL certificate association with IIS, I used the following command:

HTTPCfg query ssl

And I saw the following o/p:

So I thought I got the HASH required and tried the following command to archive the SSL certificate to folder store:

msdeploy.exe -verb:sync -source:cert=MY\db1209c20e1be61a4d86644067604118ee7dfa -dest:archiveDir=c:\CertArchive

As you expected, (and reason behind this post) it failed. Have a look at following screenshot:

 

It failed the first time because I copied the HASH directly from the HTTPCFG output. It failed due to space in a hash. I removed the spaces and tried second time and it failed too very strange error. "Certificate not found in store". I checked and double checked that certificate does exist, certificate is marked with private key exportable and IIS website with SSL certificate is working over SSL connection. Out of clue and permutations and combinations!!

Takeaway:

I forwarded the problem to internal discussion group and within minutes I got reply from Andreas Klein and that was amazing.

I executed the following command:

HTTPCFG Bug 

Do you notice the random spaces in Hash? They are actually not space. They are '0' that human eye cannot see!!!!!!!!

E.g. A certificate Hash reported by HTTPCFG as "db12 09c20e1 be61a4d86644067604118ee7dfa" should actually be "db12009c20e10be61a4d86644067604118ee7dfa". Instead of 0, HTTPCFG report it as ' '.

There is a problem in a way that HTTPCFG reports the certificate hash. I hope it will save some of your time while doing Migration with MSDeploy.


How To Use MSDeploy to Migrate Global Assembly Cache


Hi,

I am playing with MSDeploy quite a lot these days and it is great. I just want to share information about how we can use it to install assembly in GAC.

I wrote a strongly typed assembly for a test and installed it on my Windows 7 laptop. Here is an information about that assembly:

 

Here is syntax to synchronize assembly from my machine to other machine:

msdeploy -verb:sync -source:gacAssembly="' AssemblyUday, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c7ae5fd536683962'" -dest:gacAssembly,computername=ARRMSD,username=administrator@contoso.com,password=Pa$$w0rd

 

Alternatively, if you do not want to synchronize between machines, you can archive the package and move the package files to production server and synchronize production machine with archivedir.

msdeploy -verb:sync -source:gacAssembly="' AssemblyUday, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c7ae5fd536683962'" -dest:archiveDir=c:\ToGoForProduction

Isn't it great? I think it is awesome rather using GACUTIL.EXE or MSI installer.


IIS 6.0 Log Header


Those of you, who support IIS6, it might be obvious to notice the following line at the start of IIS6 log file:

#Software: Microsoft Internet Information Services 6.0

#Version: 1.0

#Date: 2009-01-30 02:05:59

#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status  

It appeared to me that (because so far I never read exact configuration!!) when you perform following actions, HTTP.SYS will insert the extra header in log file:

1) Restart the Web Site

2) Restart the IIS Server.

3) When new log files get created.

4) Logging Configuration Changes

While troubleshooting IIS problem, I generally try to relate server event with one of those above but I caught multiple times when I could not. In addition to above list, HTTP.SYS has an idle time out for log file. To Preserve System Resources especially for server hosting large number of sites, HTTP.SYS will close the file handle after 15 minute of inactivity! So if you receive request at every 16th minute, you may notice that above header multiple times.

On a side note, IIS 6 logging is not synchronous hence you may need to wait for sometime before entries get flushed to disk and it is frustrating! I believed that restarting website or IIS server will force logbuffer to flush the entries but more often than not, it is not possible in live environment just to flush logbuffer. I also believed that changing Logging configuration forces IIS to write the log to disk but that is not the case either.

However in IIS7, we have a new option. Try following command by yourself to see the result, if you haven't:

netsh http flush logbuffer