locked
WHS-hosted apps: where to install, UNCs versus drive letter paths, etc. RRS feed

  • Question

  •  

    OK, so I've been evaulating WHS beta/RC and just installed the RTM bits... working great.  Now it's time to get serious about developing/porting some apps for the platform.  Smile

     

    While WHS is being (rightfully) positioned as a generic server platform for the home, one thing that hasn't been clearly stated (at least not anywhere I've seen) is guidelines for the use of WHS-local disk resources by apps running on the server.

     

    One bit that has been made clear is that it's a good idea to put a minimal amount of stuff on the C: drive... not only is the partition (intentionally) small, but it is subject to a complete wipe/reimage if the system disk dies.  So I understand that I should install the "app part" of applications (or at least drive-letter-fussy ones) on C: and do my best to put the app's data storage (databases, tables, mail spools, etc) on the data drive... in other words, "pollute" the C: drive as little as possible.

     

    Now, here's where my questions start:

     

    1) Can/should I just make a folder on the D: drive (e.g. D:\Mail) and put app-related stuff in there?  Or is it *required* that I make a folder in D:\folders (e.g. D:\folders\Mail) or a (private) share in D:\shares (e.g. D:\Shares\Mail)?

     

    2) Is it OK/recommended to access shares or folders (e.g. \\SERVER\Mail) using a drive letter path (e.g. D:\shares\Mail) for server-based apps that may not be UNC-friendly?

     

    3) More generally, what are the guidelines for using D: so that

    (a) WHS doesn't break

    (b) Drive Extender doesn't break

    (c) data (files and/or database tables) stored on D: are not corrupted by Drive-Extender-related activities (storage balancing, folder replication, etc)

     

    Thanks for clarifying all of this...

     

     

    tkarp

    Sunday, October 14, 2007 6:42 PM

Answers

  • WHS provides the concept of an "Application Folder" where you can store data used by your application, enable duplication, etc. Look these up in the SDK for more info. A couple caveats:

    - Duplication is not enabled by default (I believe)

    - Do NOT store exe's, dll's, or any constantly open files (like a database) (your item 3.C above).

     

    If you don't use much disk space you'll likely be fine running out of c:\program Files\. If you need more space, run off of a directory on D:. If you want duplicated data stored, use an Application folder for those files.

     

    I believe UNC drives for local access on the server are not recommended, you should access those locations through drive letter (D:\shares\*).

    Sunday, October 14, 2007 7:48 PM
    Moderator
  • I would disagree that WHS is being "positioned as a generic server platform for the home". WHS can be used that way, because it's built on top of a version of Windows Server 2003, but it's not designed to be used as a generic server. Microsoft has said that all the administration tasks you should ever have to perform can be done by using the WHS Console application.

    That said, you can run a wide range of additional server applications on WHS. I would caution against running desktop applications, because they're typically going to require an interactive session on the server, and WHS isn't intended to be used as a desktop OS. Such use risks server instability, which is a bad thing if you're planning to use WHS as a repository for important data.

    But in general, if you're planning on installing a resource-intensive application, I would highly recommend installing a drive specifically for this use and omit it from the storage pool. That gives you dedicated storage that won't impact WHS operations in any way.

    To answer your questions:
    1. You can make a folder on the D: partition. Data placed there reduces the amount of data you can copy to your server in one shot, because D: acts as a sort of "landing zone" for the files. If you decide to do this, you should put it outside of the D:\Shares path. Microsoft warns us that all file access to the network shares should be done through the network shares, even locally.
    2. It should be okay to map a drive. I haven't tested extensively, so I can't speak to long-term issues, but you can certainly map and access a drive.
    3. Stay out of the folders you see already present. If you must use D: for some reason, create your own folder in the root.
    Sunday, October 14, 2007 10:04 PM
    Moderator
  •  Tom Karpowitz wrote:

    Let's take the specific example of MP3 files stored in \\SERVER\Music.  Let's suppose I have a service that I want to install on my WHS server which wants to operate on the MP3... perhaps catalog and update their ID3 tags.  What path does/should/can the app use to actually access the MP3 files on the server?

     

    1) \\SERVER\Music

    2) D:\Shares\Music

    3) map drive X: to \\SERVER\Music, then use X:

    4) map drive X: to \\localhost\Music, then use X:

    5) something else I'm not thinking of

     

    If you want to access the existing music share you should use \\%COMPUTERNAME%\Music (you shouldn't assume that the computername is SERVER). If your application has it's own data (but not files that are accessed through other apps) you should use Application Folders.

    Monday, October 15, 2007 8:56 AM
  • Monday, October 15, 2007 4:00 PM
    Moderator
  •  yakuza wrote:
    Ken and I may have both been right:
    Uh, no, actually Bezalel Geretz and you are right. Application data should be stored in application folders. This permits application data to be managed in the same fashion as other data stored on WHS, i.e. duplication and migration off of D: should both be available.
    Monday, October 15, 2007 7:59 PM
    Moderator

All replies

  • WHS provides the concept of an "Application Folder" where you can store data used by your application, enable duplication, etc. Look these up in the SDK for more info. A couple caveats:

    - Duplication is not enabled by default (I believe)

    - Do NOT store exe's, dll's, or any constantly open files (like a database) (your item 3.C above).

     

    If you don't use much disk space you'll likely be fine running out of c:\program Files\. If you need more space, run off of a directory on D:. If you want duplicated data stored, use an Application folder for those files.

     

    I believe UNC drives for local access on the server are not recommended, you should access those locations through drive letter (D:\shares\*).

    Sunday, October 14, 2007 7:48 PM
    Moderator
  • I would disagree that WHS is being "positioned as a generic server platform for the home". WHS can be used that way, because it's built on top of a version of Windows Server 2003, but it's not designed to be used as a generic server. Microsoft has said that all the administration tasks you should ever have to perform can be done by using the WHS Console application.

    That said, you can run a wide range of additional server applications on WHS. I would caution against running desktop applications, because they're typically going to require an interactive session on the server, and WHS isn't intended to be used as a desktop OS. Such use risks server instability, which is a bad thing if you're planning to use WHS as a repository for important data.

    But in general, if you're planning on installing a resource-intensive application, I would highly recommend installing a drive specifically for this use and omit it from the storage pool. That gives you dedicated storage that won't impact WHS operations in any way.

    To answer your questions:
    1. You can make a folder on the D: partition. Data placed there reduces the amount of data you can copy to your server in one shot, because D: acts as a sort of "landing zone" for the files. If you decide to do this, you should put it outside of the D:\Shares path. Microsoft warns us that all file access to the network shares should be done through the network shares, even locally.
    2. It should be okay to map a drive. I haven't tested extensively, so I can't speak to long-term issues, but you can certainly map and access a drive.
    3. Stay out of the folders you see already present. If you must use D: for some reason, create your own folder in the root.
    Sunday, October 14, 2007 10:04 PM
    Moderator
  • Good info, Ken. I was just wondering the same thing as I started setting up my fresh install of OEM.
    I installed on C:/  AVG 7.5 Network Edition AV, Handy Backup and Diskeeper Beta for WHS.  I'm down to 15 gb on C:/.

    I still have to install TVersity and uTorrent as a service like I had with RC1. I think this time I'll install those on a 200 gb drive I currently don't have in the pool. That way it won't polute and further deplete my C: drive space.

    Any issues running these programs (or any) as a service when installed on a drive outside the storage pool?


    Monday, October 15, 2007 12:49 AM
  • No, there's no issue with installing programs on non-pool drives that I know of.
    Monday, October 15, 2007 5:08 AM
    Moderator
  • Hi Ken,

     

    Thanks for your reply.  (And thanks to yakuza for your reply as well.)

     

     Ken Warren wrote:
    I would disagree that WHS is being "positioned as a generic server platform for the home". WHS can be used that way, because it's built on top of a version of Windows Server 2003, but it's not designed to be used as a generic server. Microsoft has said that all the administration tasks you should ever have to perform can be done by using the WHS Console application.

     

    Sorry, I believe my imprecise choice of words lead to some confusion here.   I didn't mean to imply that I considered WHS to be a generic server (i.e. just another installation of WS2K3), but rather (as Microsoft stated repeatedly at WinHEC and elsewhere) that it is a server platform, i.e. a place on which to host and centralize long-running, headless service applications on the home network.  They made these statements specifically to reinforce their desire to develop a third-party market for additional server services (PVR apps, home automation apps, calendar apps, whatever-you-want-that-runs-as-a-headless-service apps) to run on WHS to make it more than just a "fancy backup and remote access box".

     

    My intent is to develop/port server service applications to run on WHS, completely integrated with the expected headless WHS addin/admin model.

     Ken Warren wrote:
    But in general, if you're planning on installing a resource-intensive application, I would highly recommend installing a drive specifically for this use and omit it from the storage pool. That gives you dedicated storage that won't impact WHS operations in any way.

     

    That would certainly be my preference, especially if I were installing something with significant disk resource issues such as MySQL or SQL Server.  But I am also running WHS on a FrankenBox (i.e. a homebuilt WHS system).  I would expect that many/most "normal" WHS users who want to use my app will be running on a dedicated OEM WHS hardware solution where a dedicated drive may not have been considered.  (Yes, I suppose there's always the option of forcing the user to add a USB/Firewire/eSATA/whatever drive to support such an app, but IMHO that's a crappy answer. )


     Ken Warren wrote:

    1. You can make a folder on the D: partition. Data placed there reduces the amount of data you can copy to your server in one shot, because D: acts as a sort of "landing zone" for the files. If you decide to do this, you should put it outside of the D:\Shares path. Microsoft warns us that all file access to the network shares should be done through the network shares, even locally.
    2. It should be okay to map a drive. I haven't tested extensively, so I can't speak to long-term issues, but you can certainly map and access a drive.
    3. Stay out of the folders you see already present. If you must use D: for some reason, create your own folder in the root.

      OK, I get the part about the "landing zone" -- thanks for the clarification.  And I understand about where to install the app, and the pros and cons of using C: versus D:.  But I'm still not clear on one point, as it seems your answer to (1) conflicts with yakuza's...

       

      Let's take the specific example of MP3 files stored in \\SERVER\Music.  Let's suppose I have a service that I want to install on my WHS server which wants to operate on the MP3... perhaps catalog and update their ID3 tags.  What path does/should/can the app use to actually access the MP3 files on the server?

       

      1) \\SERVER\Music

      2) D:\Shares\Music

      3) map drive X: to \\SERVER\Music, then use X:

      4) map drive X: to \\localhost\Music, then use X:

      5) something else I'm not thinking of

       

      Which of these are valid/bad/recommended?

       

      Thanks again for your input!

       

       

      tkarp

       

       

      Monday, October 15, 2007 5:25 AM
    1.  Tom Karpowitz wrote:

      Let's take the specific example of MP3 files stored in \\SERVER\Music.  Let's suppose I have a service that I want to install on my WHS server which wants to operate on the MP3... perhaps catalog and update their ID3 tags.  What path does/should/can the app use to actually access the MP3 files on the server?

       

      1) \\SERVER\Music

      2) D:\Shares\Music

      3) map drive X: to \\SERVER\Music, then use X:

      4) map drive X: to \\localhost\Music, then use X:

      5) something else I'm not thinking of

       

      If you want to access the existing music share you should use \\%COMPUTERNAME%\Music (you shouldn't assume that the computername is SERVER). If your application has it's own data (but not files that are accessed through other apps) you should use Application Folders.

      Monday, October 15, 2007 8:56 AM
    2. Monday, October 15, 2007 4:00 PM
      Moderator
    3.  yakuza wrote:
      Ken and I may have both been right:
      Uh, no, actually Bezalel Geretz and you are right. Application data should be stored in application folders. This permits application data to be managed in the same fashion as other data stored on WHS, i.e. duplication and migration off of D: should both be available.
      Monday, October 15, 2007 7:59 PM
      Moderator