I would not manually enter dates into the schedule. I would still allow for the dates to schedule based on your network logic. Since your duration goes out for an extended period in time, I would make the schedule fixed duration. Load your duration planning values, such as 200 days, load your resources, then load your work planning values. Your resources' utilization will reduce to a very low percentage.
This, however, gives the appearance that your resources are performing work on those tasks every business day at a rate of minutes a day when, in fact, a they may not touch the work for several weeks. When you are reporting to this kind of baseline, it will appear that work should progress evenly across time but actual work will jump in steps. This could be awkward to explain and analyze.

Instead, you can split the tasks across time. In other words, your planning values might be 200 hours of work and 30 days of duration but 200 days in calendar time. So you would manually split the 30 days of duration x number of times across the 200 days. This might mean you would load work days every Monday and Tuesday, then split the work so it does not start up again until the next Monday, and so on. That would require a ton of assumptions, however, and would take quite some effort to get these tasks scheduled, especially if you have a complex, large schedule with many work packages and resources.
